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President’s Corner 
by Lyle Johnson, WA7GXD 


Since the last PSR I have had the privilege to attend two major meetings. 


In late July, AMSAT-UK sponsored a meeting at the University of Surrey, near 
London, England. A years-in-the-making vacation with my four oldest sons and my 
wife was winding down in Europe and we took the opportunity to attend most of 
the four-day event. 


Virtually every aspect of the Amateur Satellite program was covered in presen- 
tations by a number of folks from all over the world. I don’t remember any 
Australians, but the other five inhabited continents were well represented. 


Packet radio was very much a centerpiece of proposed satellite programs. 


Sometime late in 1990, the Soviet Union will launch an earth resources satellite 
with an Amateur payload aboard. RS14 will include the RUDAK-2 experiment, 
developed by the German group whose RUDAK-1 experiment was included in the 
AO-13 launch. RUDAK-2 includes a number of digital modes and also marries DSP 
technology to the system to allow for very flexible configurations. This should prove 
to be a very interesting satellite! 


If you ever have the chance to go to the UK in late July, make an effort to attend 
the AMSAT-UK Colloquium. It is definitely worth the effort. 


In late September, the Ninth ARRL/CRRL Computer Networking Conference 
was held in London, Ontario, Canada. Just as the satellite conference had a large 
percentage of packet radio, the networking conference had a large percentage of 
satellite-related papers. 


Now, many of you are not on the satellites and some of you are probably 
perturbed that I am writing about them here. Please bear with me and consider the 
following. 


It is interesting to note that the adoption of AMRAD’s AX.25 protocol as a 
“standard” was done in Washington, D.C., in October, 1982. The pressure point was 
the imminent launch of Phase 3B (becoming Oscar 10 after launch). This satellite 
would have an international footprint, and some standardization of packet protocol 
was necessary to allow various packet stations to communicate. Prior to this time, 
most packeteers (maybe 200 worldwide) were running “Vancouver” protocol with 
“San Francisco” modifications. A more flexible protocol was needed. TAPR was 
preparing to implement a dynamic addressing protocol. It, too, would have had a 
problem addressing a global community. The driving force that caused us all to work 
toward a standard solution was a satellite. 


Now, the limited bandwidth of the MicroSats are driving a broadcast protocol. 
Such a protocol is needed on terrestrial links as well — just listen to the chaos just 
above 14.1 MHz as the auto-forwarding BBS’s try and get packets through. Once 
again, satellite-driven needs may be providing solutions for all of us. 


Back to the Conference 

A number of interesting papers 
were presented, and more were pub- 
lished. There seems to be some focus 
on improving HF digital operations. 
W7GHN presents a paper on a new 
scheme he dubs “Clover.” It uses 
precise frequency control and DSP 
techniques to achieve very narrow 
band operation with adaptive signaling 
techniques to battle QRN. Other 
papers included digitized speech with 
high quality at 2400 bps and forward 
error correcting codes to reduce retries. 
High-speed interface cards for the IBM 
PC bus, advances in the KA9Q TCP/IP 
software package and position location 
by using GPS satellites are also in- 
cluded. 


The Proceedings are available from 
the ARRL for $12. Worth every penny. 


Elections 

In this issue of PSR is a call for 
nominations for the TAPR Board of 
Directors. Five seats are up for grabs. 
We need folks with organizational ex- 
pertise even more than we need techies 
on the Board at this time. Twist a few 
arms and submit a name or two. If you 
can help, submit your own name. Get 
involved! 


Until January, 
Happy Packeting! 


TAPR 1991 Annual 
Meeting 


The 1991 annual membership meet- 
ing of Tucson Amateur Packet Radio 
will be held in Tucson on Saturday, 
March 2 and Sunday, March 3. Addi- 
tional details will appear in the January 
issue of Packet Stams Register and in 
bulletins through the packet BBS net- 
work and on CompuServe. 


TAPR Board of 
Directors Election 


Tucson Amateur Packet Radio is 
incorporated in the State of Arizona as 
a non-profit scientific and educational 
instution. It is recognized by the IRS as 
a 501(c)3 tax-exempt organization for 
these same purposes. 


TAPR is governed by a 15 member 
Board of Directors. Each member of 
the Board serves a three year term, 
hence there are 5 positions to be filled 
each year. Board members are ex- 
pected to attend the annual Board 
Meeting, normally held in Tucson in 
conjunction with the annual TAPR 
Membership Meeting. They par- 
ticipate in the decision-making process 
and provide guidance to the officers. 
They receive no pay and must defray 
their own expenses to attend meetings. 
Board members should be prepared to 
be active in the continuing board 
deliberations, which are conducted 
privately in a special conference sec- 
tion on CompuServe. Active participa- 
tion in TAPR activities by board mem- 
bers is important to the furtherance of 
the objectives of TAPR. The officers 
of TAPR areelected by members of the 
board at the annual Board of Directors 
meeting. 

The current members of the Board 
of Directors and the expiration date of 
their terms are: 


Skip , WB6YMH 
Lyle Johnson, WA7GXD 1992 
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Phil Kam, KA9Q 1991 * 
Don Lemley, NSPCR 1993 
Dan Morrison, KV7B 1991 * 
Harold Price, NK6K 1993 
Dave Toth, VE3GYQ 1993 


Nominations are now open for the 
seats expiring in February 1991 
(marked with an asterisk). 


To place a person in nomination, 
please remember that he or she must be 
a member of TAPR. Confirm that the 
individual is willing to have their name 
placed in nomination. Send that 
person’s name (your own if you wish 
to nominate yourself) along with your 
and their calls, telephone numbers and 
addresses. The person nominated 
should submit a short biographical 
ata to be published along with the 

jt. 


Nominations and biographical 
sketches should be submitted to the 
bot Office no later than 1 December 
1990. 


Ballots will accompany the 
January issue of PSR or will be 
mailed directly to the membership. 
Results will be announced at the 
annual TAPR Membership Meeting 
in March 1991. 
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9600 BPS FAX Test 
Results 


by Jeff King, WB8WKA 


Between 7/25/90 and 8/6/90, the 
amateur radio stations of WBSWKA 
and WAS8OOH tested a “V.29 FAX 
modem” chip, the Yamaha 7109, be- 
tween their respective packet radio sta- 
tions. Distances involved were about 
7-8 miles over urban terrain. Results 
where quite positive with respect to the 
performance of the radio link. 


Radio Equipment 
Equipment and power levels used 
are shown in the figure. Additional 


TCP/IP testing at 1200 baud. It is 
thought that there may be some incom- 
patibilities between MSYS TCP/IP 
and net/nos. Tests will be run later this 
week between two MSYS stations to 
see if this figure can be improved upon. 


In AX.25 operations, ("user” to bbs) 
Operation was, simply put, a dream. By 
using the “XF” command in MSYS, 
full packets where transferred. Setting 
“X22” alloweda full screen to be trans- 
ferred at a time. Throughput was about 
1 page a second, which worked out to 
be about 6000-8000 bits per second. 
From a “user” perspective (I was the 
user in this case) it made operating the 
BBS much more enjoyable. Since 
many of the LAN’s in the southeast 
Michigan area are crowded, the addi- 
tional speed did not go to waste. 


uses +/-5V, this needs to go. It should 
run on only +5V. Also, it needs a 
programming header and mode select 
DIP switch. 


Existing PC (a carbon copy of the 
PRUG circuit board) needs to be im- 
proved. Quite a bit of digital noise ex- 
ists on this chip and a re-layout of the 
PC board would help greatly. 


Thoughts 

While my original idea of the use of 
this modem was “networking,” more 
and more, I am beginning to feel this 
will be the next step for the end user. 
In many applications such as the DX 
cluster, TCP/IP, and BBS operation, 
the increase of speed on the user LAN, 
is becoming more important. While 
this modem should be a fine performer 


on our “network backbones,” the ease 
of implementation and the fact that IT 
CAN BE USED ON EXISTING 
RADIOS UNMODIFIED should be 
quite appealing for the amateur that 
wishes to increase LAN throughput. 


WA8BOOH 
Livonia MI 
ICOM 28A (5 watts) 


WB8WKA 
Farmington MI 
Kenwood 7950+amp 
(160watts) 

MF] 1270 TNC GLB TNC2A 

MSYS V1.080n IBMAT NOS on IBM AT 


If I may quote WA4DSY, 
“Oh where, oh where is my 
HIGH SPEED DIGITAL?" 
What this means of course, is 
that we were not able to fully 
exercise the modems due to 


radios were also tested. At WA8OOH, 
good results were also obtained with a 
215 Kenwood HT at 200-300 mil- 
liwatts. A Kenwood 7730 was also 
tested with very poor results. Past ex- 
perience with this radio and the failure 
of any PL to function correctly on it 
may need further investigation. 


At WB8WKA, tests were also run 
at power levels less then 160 watts with 
excellent results, but due to the sharing 
of the radio with one of the 
Detroit/Windsor TCP/IP LANs, run- 
ning lower power full time was not 
practical. In addition, an ICOM 2AT 
was tested at 100mw with excellent 
results. 


Signal strengths at both stations 
were full scale, even at lower power 
levels. The antenna used at WBSWKA 
consisted of a AEA ISOPOLE at 50° 
while at WA8OOH we had a Hustler 
G7 at 20 feet. All tests where con- 
ducted on 2 meters. 


Throughput 

As was to be expected, throughput 
took a dramatic step up. About one 
megabyte of files where moved via 
TCP/IP, with the throughput hovering 
around 100 bytes/sec. While this is cer- 
tainly nowhere near “9600 baud,” it 
was a significant jump over earlier 
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MSYS and/or our TNC’s not 
being able to go beyond 9600 
baud. The TNC’s were modified for 
19200 baud operations but we ex- 
perienced dropped characters. In any 
type of KISS operation, it is important 
for maximum throughput that your 
DATA link (async link) be at least 
twice as fast as your radio link. As we 
were not able to achieve this, then our 
hope is that much faster throughputcan 
be obtained. 


General Impressions 

Audio setup is much more critical. 
Tones will tend to sound undermodu- 
lated. In addition to audio setup, a 
“keyup delay” circuit must be setup as 
well. This is due to the fact that these 
modems send a “training sequence” 
upon keyup. This must be held off until 
the radio is fully keyed up (generally 
100-200ms). Once these parameters 
are set up, things seem to be fairly 
stable and the modems can be relied 
upon in day to day operations. 


Improvements 

An easier method for tuneup needs 
to be developed. If possible, mounting 
inside the TNC would also help. Cur- 
rent carrier detect in the Yamaha chip 
is useless, We have been unable to get 
the state machine DCD to work on this 
chip but it is needed. Current layout 
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What's Next? 

In the next week or two, I need to 
te-layout the circuit board to include 
the im ts I have found. In ad- 
dition, I DESPERATELY need 
schematics for TNC’s. I have 
schematics so far for the TNC1, TNC2, 
PK232 and DRSI. If you have 
schematics for any other TNC, 
PLEASE send a copy to the address 


below: 
Jeff King WBSEWKA 
22616 Maple Ave 
Farmington, Ml 48336 
Also, if you would like copies of the 
article describing this chip, please send 
a SASE to me at the above address. 


Bota Test 

So far, about 16 people have ex- 
pressed interest in participating in a 
beta test of this modem. What this basi- 
cally means, is that we will all get 
together and make a group buy of parts 
and such to reduce our costs. In addi- 
tion of course, to the sharing of infor- 
mation that a bet test implies. With a 
professionally done PC board and all 
parts I expect costs to be on the order 
of 60-70 dollars. This is assuming we 
can get a decent discount of the 
Mt (fax chip) as it alone goes for 

551 
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FAX Modems and 
Packet Radio 


by Lyle Johnson, WA7GXD 


Background 

There has been a lot of interest ex- 
pressed in recent months about faster- 
than-1200 bps operation of packet on 
2 meters. 


Kantronics pioneered in the faster- 
than-1200 bps area commercially 
when they offered the KPC-2400, a 
2400 bps QPSK modem system as part 
of their KPC line. This didn’t gain wide 
acceptance, although MFJ has now 
joined the fray with a “turbo” option 
for their TNCs. Like the Kantronics, 
this is based on an Exar QPSK chip. 


More recently, Japan’s Packet 
Radio User’s Group (PRUG) has been 
experimenting with V.29 FAX 
modems for the past couple of years. 
The Pacific Packet Radio Society 
(PPRS) ran an experiment using these 
modems in the San Francisco area 
several years ago. 


V.29 is an intemational standard 
that specifies a method to send data at 
9600 bps over the standard telephone 
network in a half-duplex fashion. It is 
this standard that is implemented in 
virtually all of today's FAX machines. 
Part of the interest in adapting these 
modems to packet use lies in the fact 
the FAX market has mushroomed, 
making single-chip modems for V.29 
widely available at reasonable prices. 


Other experimenters have es- 
chewed V.29 and made use of direct 
FSK systems. Most of this work is 
based on efforts made by Steve Goode, 
KONG, and reported several years ago. 
The most recent incamation of Steve's 
system is the G3RUH modem which is 
becoming quite common. 

The advantage of a FAX orga 
approach is that no m 
needed to your radio. You fait at- 
tach it to your TNC as you would any 
other TNC modem and you are ready. 
The direct FSK systems require con- 
nections to the modulator and 
demodulator inside the radio, bypass- 
ing the audio circuits, deviation 
limiters, and so forth. In other words, 
you have to take the covers off, do 
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some work and have access to some 
test equipment. 


A Little Analysis 

With a number of you asking me 
about this technology, I thought I 
would perform some simple analyses 
and report to all of you via this issue of 
PSR. 


Most radios in common use on 2 
meter packet seem to take around 300 
mSec to key up and stabilize, and have 
the other station’s radio detect your 
signal and also stabilize. This cor- 
responds to a setting of TXD 30 ona 
TNC 2. 


V.29 FAX modems require a 253 
mSec keyup period beyond the radio's 
in order to send a special “training 
sequence” which the 
receiving FAX chip 
uses to synchronize 
and match itself to the 
radio channel (includ- 


MODEM 
1200 bps Exar 


ing the radio transmit | 2400 bps QPSK 
and receive filters) | 2400 bps FAX 
response. This adap- | 4800 bps FAX 
tive equalizing is | 9600 bps FAX 
what allows these | 9600 bes FSK 
chips to work with al- | 9600 bps ROC 
most any radio. 

A direct FSK sys- 
tem, on the other hand, requires you to 
get the radio system properly matched 


up. As a result, it needs only a few 
mSec to get the “scrambler” 


1200 bps and 2400 bps systems 
likewise only need a few mSec to get 


synchronized to the incoming signal. 

I wrote a spreadsheet to analyze 
tadio performance making the follow- 
ing assumptions: 

1) A prioritized ACK would be sent 
at the conclusion of an originating 
frame; 

2) No delays for random backoff are 
considered: 

3) No data is piggybacked onto the 
ACK (RESPTIME 0 in a TNC 2); 

4) No digipeaters are in the path. 

Three different data sizes were con- 
sidered: 1 single frame with an 80-byte 
data field, a single frame with a 256- 
byte data field, and amaxframe 7 trans- 
mission with all data fields equal to 
256 bytes. This corresponds to a typi- 
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cal keyboard-to-keyboard user, a file 
transfer scenario, and something in be- 
tween. 


I also ran this same set of data with 
radios that turnaround in 40 mSec 
(most 2 meter multimodes, such as the 
Kenwood TS-711A, meet this require- 
ment) and again with radios that turn- 
around in 10 mSec (like the Kantronics 
DVR). 


The FAX modem chips also offer 
4800 and 2400 bps data rates. I have 
included them in the tables that follow 
for comparative purposes. Finally, | 
have included a “ROC” (Rockwell) 
FAX modem with a fast-train option. 
While this isn’t available as a single- 
chip yet, it is available as a small PC 
board assembly. 


TABLE 1 - 300 mSec Radios 


DATA FIELD 


See Table 1. With a slow radio 
sending short frames, such as in a key- 
board QSO, the variation in perfor- 
mance is no more than 50% better than 
1200 bps. The fastest method (9600 
FSK) would take 0.73 seconds (.334 + 
401) compared to 1.4 seconds (.433 + 
.967) at 1200 bps. The 9600 bps FAX 
modem takes 1.25 seconds, hardly an 
improvement over 1200 bps at all. 


At the other extreme, file transfer, 
1200 bps takes 13.5 seconds while 
direct FSK takes 2.2 seconds - 6 times 
faster! The FAX modem takes 2.75 
seconds, which isn’t much worse than 
the FSK case. 


The 4800 bps FAX mode is better 
at keyboard QSOs than the 9600 bps 
mode (!) but falls off as the frames get 
longer, taking nearly 4 seconds to send 
a file and get an ACK. 

Finally, the Rockwell modem is 
nearly as fast as the direct FSK in all 
cases. 

What if we have a faster 
radio? Let’s look at the 40 mSec (mul- 
timode radio class) case; see Table 2. 
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TABLE 2 - 40 mSec Radios 
DATA FIELD 


0.173 
0.117 
0.189 
0.143 
0.332 
0.074 
0.105 


As might be expected, the 1200 bps 
case shows little difference when 
transferring files, while all 9600 bps 
methods show little variation amongst 
themselves with large blocks of data. 


The direct FSK system is faster in 
all cases, again with the Rockwell sys- 
tem a close second. 


A9600 FAX modem system needs 
0.73 seconds for a keyboard transmis- 
sion and ACK, a 1200 bps system 
needs 0.88 seconds. The best to worst 
ratio is now 7.7, compared to 6 with the 
slower radios. 


Moving on to a 10 mSec radio sys- 
tem, we get the results in Table 3. 


These results are almost the same as 
with the 40 mSec radios. The biggest 
difference here is in the use of direct 
FSK for keyboard QSOs. An exchange 
would only take 0,155 seconds. We 
could get almost nine QSOs crammed 
in the same 1.4 seconds our present 
system with 300 mSec radios at 1200 
bps takes for a single exchange! 

To get a better idea of what radio 
tumaround time buys us with fast 
radios (or costs us with our present 
clunkers), let’s look at Table 4. 


MOOEM 
1200 bos Exar 
2400 bps QPSK 
2400 bps FAX 
4800 bps FAX 
9600 bps FAX 
9600 bps FSK 
9600 bps ROC 


We can see from this that slow data 
isn't hurt too badly by a slow radio if 
we are sending long files, but it costs 
us a lot if we are sending short bursts. 
In the 1200 bps case, the slow radio 
costs us 100% more time, but only 3% 
more when sending files. 


In fact, faster radios would buy us 
about double at any data rate with the 
modems under consideration. 


At the other end of the data 
spectrum, sending files, the slow radio 
costs us 26% with the FAX modem. 


Closing Thoughts 

If the 9600 FAX modem is better in 
all cases, should this become a new 
“standard” for TNC’s? 


If life were really this simple, it 
might. But there are four things that 
detract from using it. 

The first is cost. The FAX modem 
chip that is presently the least expen- 
sive is the Yamaha YM7109C. It costs 
around $40 in small to medium quan- 
tities. Contrast this to the $10 cost of a 
typical 1200 bps modem, and you get 
anet increase in cost to manufacture of 
about $30. This would translate to a 


Table 4 - 1200 bps, 2400 bps and 9600 FAX with Various Radios 
2400 bps QPSK 9600 bps FAX 
BOEX __256°7EX BDEX 267°7EX 


MODEM 

OATA FIELD 

BADIO SPEED 
10 mSec 0.84 
40 mSec 0.88 


1200 bps Exar 


300 mSec 1.40 13.49 1.02 


The 80EX means 80 byte info ex- 
change (includes ACK); the 256*7EX 
means a maxframe, maximum length 
packet with ACK. 
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1293 0.44 
1297 050 655 073 224 


649 067 2.18 
707) 0125 2.76 


retail price increase of $50 to $90. 
Thus, your $129 TNC would cost more 
like $199. 
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TABLE 3 - 10 mSec Radios 


DATA FIELD 


The second is compatibility. There 
are hundreds of thousands of TNCs in 
the world today, and almost every one 
of them runs 1200 bps (A)FSK. The 
FAX modem chip has no compatible 
mode. Further, to run the FAX chip in 
any mode but V.29 9600 bps requires 
a microprocessor to be hung on the 
FAX chip’s bus, further complicating 
things (meaning more money). 

The third is the S/N ratio required 
for the FAX chip to work. Most 1200 
bps systems will work with a SINAD 
(roughly S/N at the audio output jack 
of the radio) of 18 to 20 dB. The FAX 
modem chip requires 22 dB for a 
usable bit error rate. There is no free 
lunch, as they say. 


The fourth is DCD operation. Some 
sort of tone detector may be needed to 
indicate the presence of the V.29 1700 
Hz carrier. Otherwise, the 253 mSec 
training time would leave a 253 mSec 
hole in our DCD ability, which would 
mean a large number of collisions, 
reducing throughput. V.29 modems 
are expecting a private telephone line, 
not a shared radio channel, and their 
DCD is not suitable for radio use. 


Still, the advantages of sending data 
faster, perhaps being usable through 
voice repeaters, and the multi-path 
resistance of FM might make such a 
modem attractive to many packeteers, 


R.S.V.P. 

TAPR could make a kit to add into 
a TNC 2 or similar unit. Such a kit 
might cost $80 to $90 to purchase. If 
you think this would appeal to you, let 
the office know. Who knows? V.29 
may be a viable means to get faster 
operation on crowded channels... 
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Thoughts on a Dream 
Amateur Packet 
Network Trunk 


by Jack Taylor, N700 


For some time, I have been ponder- 
ing on the subject of packet network 
expansion. Our user applications seem 
to be growing faster than the networks’ 
capability to handle them. Progress is 
being made in some parts of the 
county though. The northwest has an 
extensive 220 MHz 1200 baud simplex 
backbone in place covering Montana, 
Idaho, Washington and Oregon. A few 
other states have made substantial 
backbone upgrades as well. Perhaps 
the most significant improvement is 
seen inthe northeast. The plan of attack 
there has been to avoid the typical 
“hidden transmitter syndrome” by 
cross-banding on each of their back- 
bone nodes. They claim a 5-fold im- 
provement in thruput, even at 1200 
baud, with this technique. However, as 
the complexity goes up, so does the 
expense, 

Locally (Arizona) our user base is 
fairly stable in overall numbers. If we 
put out a call for money, we can pos- 
sibly collect $1,000 if the plea sounds 
reasonable. But to install a 56k baud 
backbone trunk across the state, there 
is litle chance our local resources 
would be sufficient to fund this type of 
effort. Additionally, we have problems 
at VHF/UHF in being able to coor- 
dinate wide channel frequencies 
necessary to support the higher baud 
rates, Some of our sites have over 300 
transmitters in the vicinity which leads 
to unresolvable problems with desense 
and intermod. Even if we had a wide 
band trunk with high speed PS-186 
switches, this type of environment 
would have an adverse effect on net- 
work thruput. 

Given these circumstances, atten- 
tion then is shifted to the possibilities 
of using amateur microwave spectrum 
for packet network development. We 
know intuitively this would be even 
more expensive and complex than as- 
sembling a VHF/UHF backbone trunk. 
Butis it? We also know, that in the long 
tun, the wide channels available at 
microwave frequencies will be re- 
quired to satisfy the 1.25 Mbps streams 
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Necessary to support anticipated 
growth. It would thus seem feasible to 
explore in detail the pros and cons of 
developing an amateur high speed 
microwave packet trunking network. 


Assuming our amateur digital tech- 
nology is pushing the state of the art, 
the possibility exists that federal and 
private grants might be available to 
help fund network development. Even 
if it isn’t state of the art, it is possible 
that grants could be obtained from the 
Federal Emergency Management 
Agency (FEMA). FEMA has available 
a variety of programs which makes 
available assistance in the form of 
matching funds, or in some cases, 
100% outright grants. To qualify, the 
local packet group would have to be 
closely affiliated with its state Civil 
Defense organization. This approach 
would also be politically desirable for 
the amateur community in general. If 
Civil Defense/RACES offices had ac- 
cess to state or area wide packet net- 
works in times of emergency, it would, 
as a minimum, justify retention of ap- 
propriate amateur 
VHF/UHF/microwave bands. 


To further explore these thoughts, a 
conference on Dream Networking was 
held in Tucson on the 25th of August. 
In attendance were interested members 
of the Arizona Packet Radio Associa- 
tion (AZPRA). Rich Ide, N7LDI re- 
lated his experience with IBM where it 
was much easier to obtain surplus parts 
donated from the company, than it was 
to receive actual cash for approved 
projects. Morgan Hoaglin, WW7B 
reported as Red Cross Communica- 
tions Officer; he was in the process of 
setting up a BBS which would have 
land line access to the Arizona Red 
Cross office in Phoenix. 

AZPRA Technical Director Brian 
Cassel, WSVBO presented a paper 
outlining his ideas on the topic of “The 
DREAM Amateur Packet Radio Sys- 
tem”. He stressed the following 
(paraphrased) points: 

1) Network goals must conform to 
funding. 

2) The amount of funding will depend 
on the extent the network idea is 
“sold.” 

3) The network could be sold as: 
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a) Emergency Backup. Long 
distance carriers are working to cut 
over to fiber optic transmission 
systems within the next two years. 
Fiber systems are subject to disrup- 
tion due to earth shifts or terrorist 
attacks. An amateur network must 
have capacity to carry high 
volumes of traffic during emergen- 
cies, 

b)Emergency Weather Ser- 
vices. Off the shelf sensors are now 
available which, when installed at 
specified packet nodes, could pro- 
vide basic weather data to acentral- 
ized collection and processing 
point. This data could be made 
available to any network user for 
emergency or personal use, 


c)Microsat Applications. 
Evolving microsat technology may 
soon allow simultaneous “broad- 
cast mode” exchanging of BBS 
files from orbiting packet satellites. 
Gateway ground stations could ef- 
ficiently update all BBS"s intertied 
to the network in specified areas. 
This system, if implemented, could 
greatly reduce nationwide BBS to 
BBS forwarding congestion. Also 
this technique has significant com- 
mercial or 3rd world country ap- 
plicati 

d)Educational Uses. With only 
a licensed operator, TNC and ter- 
minal, many educational oppor- 
tunities exist through the network. 
Weather and satellite categories 
could be studied at several levels 
by different layers of education. 
Such studies could include: satel- 
lite orbiting mechanics, analysis of 
telemetry, network data studies 
(MONAX type monitoring), VHF 
propagation analysis (gathered 
from NODES broadcasts) and ad- 
vanced networking concepts. The 
data from this network could lead 
to encouraging the establishment 
of more school and university 
amateur club stations. 


4) It can easily be seen that the 
development of a Dream Network 
would be of great advantage to 
many. But the amateur community 
would also be faced with the chal- 
lenge of managing and maintaining 
the system. In addition to the tech- 
nical challenge, if grant funding 
were received for network develop- 
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ment, it would be necessary to col- 
lect, maintain and submit documen- 
tation at all levels of installation and 
operation. This may be more of a 
burden than some areas have the 
capability to undertake. Obviously 
if we are to pursue this quest, we 
will have to do considerable ad- 
vance planning in all areas of or- 
ganization, operation, and main- 
tenance if it is to succeed. 


Brian further reported that some as- 
sets are currently available from one of 
the commercial companies. Art Mar- 
shall, W1FIJI said he would coordinate 
the issuance of a letter from AZPRA 
stating our interest in establishing an 
amateur microwave packet network, 
and indicating our willingness to ac- 
cept selected donations from these 
firms. AZPRA would also seek status 
as an IRS-approved non-profit entity, 
for obvious reasons. It was agreed 
before any attempts to obtain network 
funding, it would be necessary to have 
a draft network plan in hand. The plan, 
in addition to network routing, should 
address the network management is- 
sues identified above. It was generally 
understood that the Dream Network is 
a long term goal and as such, it would 
not impact the current AZPRA back- 
bone upgrade projects. 


Following the meeting, an addition- 
al thought has surfaced. If the long 
distance firms are phasing out their 
microwave systems, would there be a 
chance they might donate their 
facilities to an amateur group? This 
would be a coup indeed, if entire net- 
works could be transferred in place to 
us amateurs! Typically these systems 
go to the same locations our dream 
network would cover. There exists a 
good possibility commercial gear in 
the 4 and 6 GHZ range could be 
tweaked onto the amateur bands. From 
a systems viewpoint, it would be very 
desirable to have a trans-continental 
network placed in our care, rather than 
just focusing our attention on the local 
Arizona scene. 

But a national network would re- 
quire an organization larger than 
AZPRA to take on this responsibility. 
The question naturally arises, who? 
Would TAPR have the resources or the 
willingness? Possibly. How about the 
ARRL? Possibly. Even as a gift, the 
cost of electric and site rents might be 
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larger than what individual amateur 
groups would be able to support. 
Would a government agency be will- 
ing to underwrite operational costs for 
atrial period? Worth looking into. If it 
should be determined the amateurs 
could take on this responsibility, how 
would they go about lobbying for it? 


Large companies normally do plan 
ahead and with only two years before 
they switch over to the fiber optic sys- 
tem, they probably already have tradi- 
tional concepts in mind towards dis- 
posing of these assets. They certainly 
don’t want to see the equipment fall 
into the hands of their competitors, so 
it is quite likely they will scrap it. At 
this point in time, we don’ t know for 
certain whether or not the commercial 
firms will be unloading complete net- 
works. But if they do, donating it to the 
amateurs with the understanding it 
won’t be used commercially has good 
possibilities all the way around. It 
would seem timeliness is important 
here and negotiations should be started 
as soon as possible. 


Would it be better if “we” held 
dialog with FEMA about our plans 
with the hope they would support us, 
and in turn, negotiate a transaction 
with the commercial carriers? These 
decisions would be up to the national 
amateur organization, if any, that 
would be willing to tackle this project. 

Meanwhile, AZPRA’s best course 
is to quietly follow-up on getting into 
& position to receive any network type 
donations, should they appear. 


’ 9th Computer 


Networking Conference 


by Greg Jones, WDSIVD 


This year’s conference was jointly 
sponsored by the American Radio 
Relay League and the Canadian Radio 
Relay League. The conference was 
held at the London Regional Art Gal- 
lery and Museum, in London, Ontario, 
which provided a very nice facility for 
the conference. Harry McLean, 
VE3GRO, started the moming, before 
9am (a first?), by welcoming everyone 
to the conference and went on to say 
how ‘Proud the CRRL was to host this 
year’s network conference in Canada. 
Paul Rinaldo, W4RI, was introduced 
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and also welcomed everyone to this 
year's conference. Paul stressed the 
importance of having the Network 
Conference and also made some points 
about the future of digital communica- 
tions with respect to how we use our 
hobby. Paul continued by introducing 
this year’s honorary Sergeant-at-Arms 
— Dr. Dave “Death” Toth, VEIGYQ. 
The conference had a very good atten- 
dance this year with just over 130 
people in attendance. The large 
majority of amateurs present were 
from Canada, which was nice to see. 
The hospitality suite hosted both nights 
was a good place for everyone to meet 
and discuss what they were doing and 
what had happened that day at the con- 
ference. There were also a number of 
rooms Saturday night showing the 
latest technology in packet radio. 


Keith Sproul, WU22Z. started off the 
conference discussing work on long 
distance packet mail forwarding via 
satellite. Keith talked about future 
planned use of satellites for mail for- 
warding instead of using slow HF 
packet. He outlined a solution with 
two stations in a zone, with one receiv- 
ing full time and the second roaming to 
send traffic to other fixed stations over 
the satellite. 


Harold Price, NK6K, presented 
both his and Jeff Ward’s, GO/K8KA, 
presentations on PACSAT. Jeff was 
unable to attend. Harold spoke on why 
their first assumptions on using 
PACSATs were not correct. The 
series of five papers discuss and 
describe the current solution of a 
broadcast protocol being used current- 
ly on UOSAT 14. 


Bob McGwier, N4HY, presented an 
overview of the current RUDAK II 
design for Hanspeter Juhlen, DK1YQ. 
Bob showed a number of slides taken 
on his last trip of RUDAK II and of the 
people involved. Bob then reported on 
the latest news conceming various 
DSP projects. Bob showed the AEA 
DSP-232 box and the TAPR-AMSAT 
DSP board. The AEA unit will be a 
standalone and has over 40 modems 
currently designed for use. The AEA 
DSP is based on the Motorola 560001 
processor and design will allow users 
to upload new code into the unit as 
necessary instead of having to replace 
EPROMS. Software will be available 
for people to write their own. The 
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TAPR-AMSAT board was shown and 
is based on the TI TMS320C25 and is 
a XT/AT PC plug-in board. It will 
have similar software available. 


Glenn Elmore, N6GN, presented a 
technical overview on how the 
amateur community was utilizing 
bandwidth and discussed the need for 
high speed amateur radio network. 
Kevin Rowett, N6RCE, followed after 
Glenn and discussed the HubMaster, 
which they are building as a solution to 
support higher speed networking. 

John Bloom, KE3Z, discussed fu- 
ture thoughts about digital networking. 
What is a network of the future going 
to look like? Possibly voice/data net- 
works? These direction and goals 
need to be thought about to be able to 
compete with the other concems who 
wish to take over our resources in the 
future. Amateur Radio needs to 
present a clear plan on what it intends 
to do in the future. 


Armin Langi discussed a system 
called CELP which is a high-quality 
speech processing system for packet 
radio transmission and networking. 

W. Kinsner, VE4WK, discussed his 
paper on forward error correction for 


packet radio. The paper is very good 
and should be read. 


DonLemley, N4PCR, discussed the 
problems associated with current net- 
working and talked about the need for 
faster digital networking, software, 
and radios for such networks to be 
available. The PackeTen project is a 
digital hardware and software net- 
working solution which will allow 
compatibility with the standards today 
and allow for some type of transition 
in the future. 


After lunch, Phil Anderson, WOXI, 
spoke about both 9600 baud operations 
of the G3RUH with the Kantronics 
Data Engine and DVR2-2, Phil also 
discussed BPQ Node working in an 
enhanced network. 

Tom Clark, W3IWI, first discussed 
future HF operations and solutions 
with the almost available DSP 
products to implement different en- 
coding and modulation schemes to 
have better HF digital operations. Ex- 
amples of modulation schemes could 
be Multi-Tone, QPSK, or QAM. 
Second, Tom talked about how current 
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message wansfer protocols are inade- 
quate and thus cause massive amounts 
of extra congestion. Tom discussed a 
new file transfer protocol which would 
allow for a more efficient and robust 
method for transfer on HF. Tom 
finished up talking about his recom- 
mendation for handling broadcast bul- 
letins on VHF, which he calls 
BULLPRO. 


Dwayne Hendricks, WA8DZP, dis- 
cussed current development of TCP/IP 
in the Mac environment. Dwayne 
talked about the future of having this 
capability available in the new Apple 
Communications environment which 
will be available in System 7.0. This 
looks to be very promising to Mac 
TCP/IP users. 


Phil Karn, KA9Q, updated work on 
TCP/IP. Currently no new platforms 
have been finished, buta few new com- 
mands have been worked on by Phil 
and he has worked on improving 
operations at higher speeds. Phil con- 
tinued on with a discussion on his 
paper talking about MACA (Multiple 
Access Collision Avoidance). 


James Grier presented some work 
that had been done at the Air Force 
Institute of Technology conceming the 
designs for a packet network for the 
Air Force. 


Frank Warren, KB4CYC, finished 
the afternoon speaking on software he 
had developed as a utility for NTS 
work. The Station Traffic System 
software supported a variety of handy 
things to help the NTS operator. 

The day finished with dinner at 
“Captain John’s and Susie Wong's,” a 
local eatery. Much food and fun was 
had by all. There is no set location for 
next year’s Network Conference, so 
hope to see you wherever it may be! 
Stay tuned as news develops. 
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SNS and TPRS 
Agreement 


by Greg Jones, WDSIVD 


The Texas Packet Radio Society 
(TPRS) has been working with South- 
west Network Services (SNS) to make 
available to TPRS, circuits to cities in 
Texas and many other states. The lines 
now available are 9600 bps, point to 
point circuits, and our intention is to 
extend coverage of the TexNet Net- 
work to such cities having individuals 
wanting to support and join in this ef- 
fort. A few of the cities available out- 
side of Texas are Oklahoma City, 
Tulsa, Baton Rouge, New Orleans, 
Birmingham, Atlanta, and Nashville. 
These circuits are available now. Fu- 
ture cities include Denver, Los An- 
geles, San Francisco, Phoenix, and 
more, 


TPRS is the sole contact and coor- 
dinator for these services. DO NOT 
attempt to contact SNS or its 
employees for information on these 
facilities. Not every location meets all 
the needed criteria for an amateur 
packet node (i.e., roof access for anten- 
nas), but any amateurs in these or other 
such locations WHO HAVE A REAL, 
SERIOUS, HONEST interest in par- 
ticipating are encouraged to write 
TPRS stating such or you may call 
Harry Ridenour, NOCCW, at (512) 
654-4405 between 1200cdt-2300cdt. 
Such contacts will NOT be handled by 
packet. We think this is a great oppor- 
tunity and hope to be able to get inter- 
ested groups or club involved. 


Renew Your Membership! 

TAPR doesn’t send out con- 
stant reminders when your 
membership has expired. Our 
only way of communicating 


your expiration date to you, is 
the date on the address label for 
this issue. Please check it and 
renew if required. Your mem- 
bership is very important. 
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FIRST IMPRESSIONS: 


What is a “First 
Impression?” 


by Lyle Johnson, WA7GXD 


Most Amateur Radio journals con- 
tain product reviews, In many cases 
they appear to be carefully worded bits 
of diplomacy written to avoid the 
wrath of the advertisers who support 
the magazine. 


To me, a product review should in- 
clude measured performance and 
should be conducted by a person 
qualified to evaluate the product. 
Many times I have seen reviews in the 
computer press that go something like 


“The Foo-Bar C Compiler” by R. 
E. Viewer 


[ got a sample copy of the Foo- 
Bar C compiler and it is really 
neat. The manuals have lots of 
pictures and appear to have been 
printed on a laser printer. 


I have only ever p: med in 

BASIC before, teat f wanted to 

learn C and the Foo-Bar compiler 

seemed like a good choice to me. 

I loaded the sample 

“Hello.world” program and it 

worked, following the step-by- 

step instructions, 

None of the other examples 

worked, but this is because I was 

checking a beta release of the 
compiler. Foo-Bar assures me 
that the real version won't have 
any bugs. The Foo-Bar compiler 

Supports a mouse and I think Foo- 

Bar has a great product. I strongly 

recommend the Foo-Bar com- 

piler for anyone who wants a C 

compiler for their computer. 

Such reviews are a complete waste 
of paper in my opinion. 

In some Amateur journais I have 
seen reviews of transceivers by Novice 
licensees, Now, a Novice, by defini- 
tion, hasn’t had much experience in the 
field. It is useful to get a newcomer to 
assist in a review to see if the manuals 
are written so that a non-experienced 
person can correctly set up and safely 
operate the item being tested. How- 
ever, the actual review should be done 
by someone experienced in the product 
area and the equipment should be 
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thoroughly exercised in its intended 
environment and for its intended use. 


I think TAPR can serve the packet 
community by doing careful product 
reviews on equipment unique to our 
mode. 


Product reviews aside, I also think 
itis useful for Amateurs to be aware of 
new products in a less formal context. 
Itis with this in mind that I have written 
acouple of “First Impressions” for this 
issue of PSR. 


First Impressions seeks to provide a 
look at a product by “kicking the tires, 
slamming the doors and peeking under 
the hood.” 


Products will be compared with 
similar products to give the reader a 
feel for the device ina context to which 
(s)he can relate. 


A (hopefully) valuable section of 
the First Impression will be a sub- sec- 
tion entitled “Product Pointers.” 


Recommendations will not be made 
as to who should purchase this device 
or why it is the best widget since com 
flakes. Keep in mind thatan exhaustive 
analysis is impossible. Impressions are 
subjective rather than analytically ob- 
jective. Negative statements do not 
necessarily mean that a product is bad. 


Product Pointers 

This section will include “gotchas” 
and observations of differences in the 
product from that which a user might 
have come to expect while using 
similar products. 

In particular, information will be 
included here to clarify features or 
functions of the product that might 
otherwise cause confusion or frustra- 
tion. 


Conclusion 

I would greatly appreciate feedback 
from as many of you as care to write to 
me. There are two First Impressions in 
this issue of PSR. I would like to know 
if you find the information useful, the 
format adequate, what improvements 
you would like to see in the format, 
suggestions, etc. 

Please let me know through the 
TAPR office address. Don’t send it via 
the packet network as this could be 
construed as conducting business! 
Thank you. 
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FIRST IMPRESSIONS: 
PacComm PSK-1 PSK 
Modem 


by Lyle Johnson, WA7GXD 


PacComm, through Digital Signal 
Systems, is the first licensee of the 
TAPR PSK modem. PSK (phase shift 
keying), due to its improved perfor- 
mance in weak signal environments, is 
used on a number of amateur satellites. 
In addition, Amateurs in various places 
are using PSK on HF and reporting 
improved performance over FSK tech- 
niques. 


Background 

FO-12, launched in 1986 and in ser- 
vice until late 1989, pioneered the use 
of 1200 bps PSK satellite communica- 
tion in Amateur radio. The TAPR PSK 
modem design is based on a design 
from the JAMSAT FO-12 team. 


The satellite designers chose PSK 
as the modulation format due to the 
inherently greater efficiency of PSK as 
a simple modulation technique. 


In fairness, it should be pointed out 
that the 20 to 25 dB improvements of 
“PSK versus FSK” quoted several 
years ago from some sources were 
comparing AFSK/FM (standard 2- 
meter packet practice) to PSK through 
a linear (SSB) system. This was an 
apples-and-oranges situation, because 
a PSK modem run through an FM 
transceiver will be markedly worse in 
terms of weak signal performance than 
a pure PSK system. 


UO-14, for example, uses a pure 
FSK system at 9600 bps and is working 
quite well in the Amateur Satellite Ser- 
vice. 


DO-17 (DOVE) uses AFSK/FM on 
145.825 MHz. It is pretty easy to com- 
pare the results of copying a DOVE 
pass versus copying a PSK-based 
MicroSat pass (PSK wins). 


Until the PSK-1, you had three 
choices for obtaining a PSK modem: 
buy a kit from TAPR, buy a kit from 
G3RUH, or home-brew one. The Cos- 
tas Loop design used in the TAPR sys- 
tem is theoretically capable of 3-6 dB 
better weak signal performance than 
the squaring loop used in the other 
design. 
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Design Features 
The PSK-1! offers a number of new 
features in the PSK modem design: 


1) AGC to improve tolerance of the 
demodulator to widely varying signal 
strengths. 

2) Internal microprocessor to allow 
setup re-configuration. 


3) Capability to demodulate and 
decode 400 bps PSK telemetry frames 
from AO-10 and AO-13 spacecraft. 


4) Front panel diagnostics via mul- 
tiple LED display. 


5) Setup can be changed through a 
rear-panel serial port or via two buttons 
on the front panel. 


Common Features with Other 
PSK Modems 

1) Automatic doppler tracking of 
the received signal. 


2) Tuning display to make it easier 
to acquire the satellite (or other PSK) 
signal, 

3) Ability to bypass the PSK 
modem and re-connect your TNC’s 
(A)FSK modem to your 2-meter radio. 


4) Selectable polarity of the doppler 
tracking output. 


Front Panel 

The PSK-1 front panel consists of a 
Power LED to indicate power is on, a 
bargraph display for tuning, a LOCK 
LED to indicate that the PSK 
demodulator has achieved 
synchronization with the received sig- 
nal, and UP and DOWN LED's to in- 
dicate the direction you should tune 
your radio (or the direction it is tuning 
your radio) to track the received signal. 
This latter is used for tracking doppler 
shift at 70 cm when receiving satellite 
signals, 


Rear Panel 

The rear panel has VHF and UHF 
radio 5-pin DIN connectors, an 8-pin 
DIN modem disconnect, power jack, 
an 8-pin mini-DIN serial port connec- 
tor for commanding the PSK-1 and 
monitoring 400 bps telemetry, and a 
power switch. 


General Impressions 

The PSK-1 comes with a complete 
set of cables and connectors for every- 
thing but the serial port. I think an 
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unterminated connector for this pon 
would be useful for most Amateurs and 
expected to have found one in the box. 
Spares for all the connectors except 
this one are readily available through 
sources such as Radio Shack. 


The IC’s are socketed (I personally 
like this for roubleshooting purposes). 


I have interfaced the PSK-1 to a 
TAPR TNC 1, TAPR TNC 2, AEA 
PK-232 with TAPR modem discon- 
nhect, and a Kantronics Data Engine to 
verify the modem disconnect and 
bypass mode functions. It works well 
in analog loopback mode, demodulat- 
ing its own PSK signals over a wide 
range of input signal levels. 


My satellite antennas are presently 
out of commission, so I had to decode 
satellite passes with a simple 70 cm 
dipole antenna clamped to my window 
frame. I was actually able to decode a 
few frames with this lash-up! Hopeful- 
ly, this situation will be rectified before 
the next PSR deadline and I can give 
you an update on performance “‘on the 
air.” 


The unit I received would not 
respond to front panel switch com- 
mands, but worked OK when com- 
manded through the serial port. A few 
hours spent with the unit with an oscil- 
loscope, DVM, using the PSK-1's in- 
ternal debugger, etc., revealed the 
problem to be mechanical in nature. 
The fix is outlined in Product Pointer 
Number 5, below. 


Once operational, the front panel 
control system is quite simple to 
operate. Pressing the button labeled 
“FUNCTION?” activates the left-most 
tuning indicator LED. A label beneath 
this LED indicates the “MODE” func- 
tion has been selected. Choices for 
MODE are “SAT” “PSK” or “400.” A 
second LED will flash over one of the 
these three labels, indicating the cur- 
rent MODE. Repeatedly pressing the 
“SELECT” button will then step the 
flashing LED through the available 
choices. Simply stop pressing when 
the MODE you desire is flashing. 
Pressing the “FUNCTION” button 
again will move the indicator to the 
“MODEM” position, where the flash- 
ing LED may be placed to select “IN” 
or “OUT.” Joint/Split and AFC op- 
tions may similarly be configured. 
When no input has been received from 
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either button for a few seconds, the 
display will revert back to its normal 
function of tuning indication. 


Product Pointers 

While doing the interfacing, I ran 
into a few “gotchas” that I will point 
out in the hope it will save you some 
problems. 


1) Unlike the TAPR design, power 
must be on if the PSK-1 is attached 
to your TNC and you wish to operate 
your TNC in any mode. This is true 
even if you are not using the PSK-1. 


The TAPR unit uses physical 
switches to route the modem discon- 
nect intercepted RXD and DCD sig- 
nals, as well as to route the radio con- 
nector audio signals. Thus, power can 
be removed when the TAPR PSK 
modem is bypassed. 

The PSK-1 uses CMOS switches 
under control of the internal 
microprocessor. Therefore, power 
must be applied to the PSK-1 if it is 
cabled to your TNC. 


2) The transmit circuit requires a x8, 
x16 or x32 clock to generate 
“manchester” transmissions to the 
various satellites. The proper clock 
selection must be made for the satellite 
to be able to decode your transmission. 
This option is not selectable from the 
PSK-1 front panel or serial port. It is a 
jumper than must be physically posi- 
tioned on the PSK-1 PC board. 


The jumper comes from the factory 
set for x16. This is suitable for TNC 2- 
based TNCs such as the MFJ units, 
PacComm Tiny-2 and Micro-2 and 
TNC-200s, GLB TNC-2A, AEA PK- 
80 and TAPR TNC 2. 


The x32 position is needed for 
TAPR TNC 1, Heathkit HD-4040, 
AEA PKT-1, AEA PK-232, 
Kantronics Data Engine and other 
TNCs using an 8530 HDLC chip. 


The PSK-1 manual correctly refers 
you to setting jumper JP6 to pins 5&6 
to get x32 operation. Unfortunately, 
the present manual doesn’t show the 
pinout of the JP6 and it is opposite to 
what you might intuitively expect. 


Refer to the illustration for place- 
ment information regarding JP6. 


3) The unit will not do loopback in 
“manchester” mode. To do this would 
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4) The UHF radio connector is 
not compatible with the TAPR PSK 
modem! 


Unfortunately, the connector is 
physically identical to the TAPR con- 
nector. 


Itis unlikely that damage will occur 
if you mix up these cables. It is guaran- 
teed, however, that your system won't 
work if you use a TAPR cable with the 
PSK-1 or vice versa. 


Most folks don’t have both a TAPR 
and a PacComm PSK modem, but for 
those that do, and have already wired 
upa TAPR cable, an adapter cable will 
sort things out for you. I don’t know if 
PacComm intends on changing the PC 
layout to correct this incompatibility. 


The PSK-1 uses a different method 
to step the radio. There may be a prob- 
lem when stepping ICOM radios with 
this cable, so check your radio manual 
first! It should work OK with Ken- 
wood and Yaesu radios (radios that use 
GND or +5 volts to command step- 
ping). 

5) The front panel switches... 


unit is smaller than the cabinet by a few 
ten-thousandths of an inch, allowing it 
torattle slightly. The front panel usual- 
ly exerts slight pressure on a plastic 
part of the switch, causing it to appear 
to be activated to the internal 
microprocessor, which eventually ig- 
nores the depression. 


The fix was simple. I added a small 
washer between the front panel and the 
cabinet’s plastic bezel. This spaces the 
front panel far enough away from the 
PC board that the switches are free. 
The front panel selection system now 
Operates flawlessly. 

PacComm indicates that future 
boards will be reconfigured to recess 
ha switches so this will not be a prob- 


6) Be sure to read the manual for an 
important tip when placing the PC 
board into the case. There is a voltage 
regulator tab that must slide into a spe- 
cial groove for proper heatsinking. 
This is found on page 22 in the March 
1990 edition of the PSK-1 manual. 


ADAPTER CABLE 


DIN 5-PIN MALE 
TO PSK-1 UHF 
SS 


2 
4 
3 
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DIN S-PIN FEMALE 
TO TAPR PSK CABLE 
—oo-eeer 


FUNCTION 
STEP UP 
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by Lyle Johnson, WA7GXD 


The Kantronics Data Engine is the 
(digitally) highest-performance TNC 
currently on the market. 


It is based on the NEC V40 
microprocessor chip and the Zilog 
8530 SCC HDLC controller. It in- 
cludes 64k bytes of RAM and EPROM 
standard, and is expandable to 256k 
bytes of RAM and 768k bytes of ROM 
using parts available today. The radio 
HDLC ports are interfaced to the 
Microprocessor using a technique 
called direct memory access (DMA). 
This means that an incoming (or out- 
going) packet can be received or sent 
without the microprocessor having to 
deal with each and every character or 
byte. The processor only intervenes on 
a frame-by-frame basis. 


What this means to the user is that 
the Data Engine can loaf along with 
both radio ports running at 56 kbps. 
However, unless it is running as a 
packet switch, there will be problems 
getting all that data into or out of your 
PC’s asynchronous serial port! The 
real meaning here is that this TNC 
shouldn't have a problem running 
9600 bps, or even 56 kbps, in your 
shack. 


The Data Engine is modular in con- 
cept. The basic TNC is a four-layer 
“motherboard” into which optional in- 
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ternal modems may be installed. It has 
space for two such modems. 


Like most Kantronics products of 
recent vintage, it allows both radio 
ports to be operated simultaneously. 
The unit may thus serve asa “gateway” 
between the ports. 


Unlike other Kantronics offerings, 
this one is designed around a standard 
hardware HDLC chip, making modem 
interfacing a simple task rather than a 
difficult or impossible chore, See “In- 
terfacing the TAPR PSK Modem to the 
Kantronics Data Engine” elsewhere in 
this PSR for an example. 


Design Features 
The Data Engine offers the follow- 
ing new ideas to the TNC marketplace: 


1) Lots of memory. This gives plen- 
ty of space to buffer packets, provide 
message storage for the “personal 
mailbox” feature, keep up with new 
protocol enhancements, etc. 


2) Fast HDLC I/O. DMA allows 
operation at 56 kbps. With careful 
software design, it may be capable of 
even faster operation... 


3) Plug-in modems, There is no 
hard-wired modem on the TNC's main 
PC board. 


4) Multi-layer PC board. The Data 
Engine uses a 4-layer PC board. This 
contributes to better RF interference 
characteristics (but is no guarantee of 
“quiet” operation). There are a couple 
of other multi-layer boards I am aware 
of in pocket-size TNCs (from Heath 
and PacComm) but this is the first “full 
size” unit to offer this technology. 


5) LOAD mode. This allows you to 
upload user-written software into the 
Data Engine and exercise it. Primarily 
useful for software developers. 


6) G8BPQ has written code that fits 
in an EPROM and makes the Data 
Engine a dual-port packet switch com- 
patible with NET/ROM protocol. The 
EPROM image for this is available 
from the Kantronics BBS. 


Other Features 
Features the Data Engine shares 
with other TNCs includes: 


1) TAPR-style command set. 


2) KISS interface (mostly used with 
TCP/IP and satellite operation). 
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3) HOST mode. 


Kantronics has defined a new host 
mode and included it in the Data En- 
gine. Until now, only WA8DED 
EPROMs and AEA products offered 
this feature. The Kantronics im- 
plementation is different than the 
WA8DED interface, which is in turn 
different than the AEA interface. 


4) Radio ports. 


The Data Engine uses a 15-pin DA- 
15S connector. Kantronics consulted 
with TAPR during the design phase of 
the Data Engine to maintain com- 
patibility with the radio inter- 
face port of the TAPR/AMSAT DSP 
project. 

Along with the modular concept of 
the Data Engine, a few internal 
jumpers allow the radio port to be used 
as a modem disconnect. This makes it 
relatively straightforward to interface 
modems that are too bulky to fit inter- 
nal to the Data Engine, A unit that 
comes to mind is the GRAPES 
WAG4DSY 56 kbps modem. 


I interfaced two different external 
PSK modems to the DE1200 port. See 
the article elsewhere in this PSR for 
more details, 


Front Panel 

The front panel of the Data Engine 
includes a POWER switch and an 
AUX switch. The latter is for software- 
definable features. 


There are eight (8) LEDs, labeled 
Al through A8. They provide the usual 
PTT, DCD, CON and STA functions 
under software control, More about 
these under “General Impressions,” 
below. 

There are two “windows” in the 
front panel to allow internal modems 
to provide displays, such as bargraph 
tuning indicators. 


panel has (radio) PORT 1 
and PORT 2 DA-15S connectors, a 
power connector for +12 vde input and 
an 8-pin RJ-series “modular phone 
jack” style RS232 connector. 

The PC board mounted interface 
connectors are of the shielded variety, 
and the rear panel cover plate is at- 
tached to the shield covers of the con- 
nectors. 
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General Impressions 

The Data Engine comes with an 
RS-232 cable, unterminated at the 
computer end. Unfortunately, this 
cable is not shielded and the connector 
type isn’t shieldable. This port sup- 
ports hardware flow control and, apart 
from the connector chosen, is com- 
patible with other TNC serial ports. 


A DA-15P connector is provided 
with each modem. The test unit had a 
single DE1200 1200 bps FSK modem, 
so a single shielded DA-15P mating 
connector was provided, along with a 
length of shielded cable to interface to 
a radio. 

A power connector with attached 
red and black wires was provided. This 
is nota cable, so I had to ty-wrap it into 
one. The power connector is not the 
normal 2.5 mm style normally en- 
countered. This connector latches 
when plugged into the TNC so 
problems of intermittent or flaky 
power connections are unlikely. 


The default setting of the DE1200 
modem (0,HALF,1200) uses the “open 
squelch” or “sine-wave” DCD circuit. 
This proved to be reliable when 
operated with Yaesu FT-208R and a 
Kenwood TS-711A FM receivers. | 
didn’t perform any measurements 
regarding DCD response time. 

An on-line “help” system provides 
brief remarks about the various com- 
mands and their arguments. This is 
possible due to the large (1 megabyte) 
address range of the V40 microproces- 
sor. 


Unlike other Kantronics products I 
have used, all IC’s on the Data Engine 
are socketed, This is not the case with 
the DE1200, but most of them are 
socketed on that board as well. As you 
have probably guessed, I am a firm 
believer in IC sockets... 


Product Pointers 

1) Opening the case and sliding the 
TNC out is simple. Just loosen the 
screws on the rear panel and catch it as 
it slides out. Re-installing it into the 
case, however, is a bear. The front 
panel LEDs seem to have a propensity 
to almost line up (seven out of eight). 
In the end, you have to remove the 
front panel, wiggle the LEDs and 
generally mess around with the unit 
before the front will co-operate. 
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To be fair, many TNCs are like this, 
including the venerable TAPR TNC 2. 


2) If you have to reset the unit by 
disconnecting the backup battery, the 
jumper is under the PORT 1 modem, 
so that device has to be removed. 


3) Use an ohmmeter to wire up the 
RS-232 cable! 


The Data Engine manual shipped 
with the unit gives an incorrect color 
code for the wires. Errata sheets 
shipped with the unit included an up- 
date page for the RS-232 interface with 
no color code given. I mistakenly as- 
sumed the color coding from the 
original manual was correct... 


4) If you have other TNC’s in your 
shack, you might want to wire up the 
DA-15 connector to an interface plug. 
All my radio cables are set up for TNC 
2 style radio connectors, so I made up 
a cable using a Radio Shack 5-pin 
female DIN connector as follows: 


5-pin 
OAI5P DIN FUNCTION 
1 3 PIT 
2 4 RX AUDIO 
3 { TX AUDIO 
8 5 RFOCD 
910 2 GND/SHIELD 
5) Front Panel 


The front panel LEDs are labeled 
Al..A8. This is OK, since they are 
software defined and their function 
could change with time, but it might be 
useful to have their “normal” functions 
printed below them. These functions 
are: 


FUNCTION PORT! PORT2 
“PIT ss ATC AT 


DCD A2 A8 
CON AS 
STA A4 

AS5 signifies “mail waiting’ 

A6 is unused 


6) COMMANDS 


The version 1.02 software uses a 
few commands that are different than 
what you are probably accustomed to. 
This isn’t bad, you just need to be 
aware of it. A few that come to mind 
are: 

PERM 
MODEM 
MONITOR 
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The TNC 1 had a PERM command 
to save user parameters. Battery-back- 
ed RAMin the TNC 2 simply saved the 
last state of the commands when power 
was removed. The Data Engine re- 
quires the use of PERM with an argu- 
ment of either “ALL” to save every- 
thing or “command” to save a par- 
ticular command (like “PERM 
TXDELAY”). Don’t make the mistake 
of customizing your Data Engine to 
your station and then turning off power 
before you PERM your changes. I 
won't mention any names, but I know 
someone who actually did this... 


Satellite users are accustomed to is- 
suing a FULLDUP ON/OFF to select 
full duplex or half-duplex operation. 
The Data Engine embeds this informa- 
tion in a MODEM command which 
specifies a setup (lines run to the 
modem board from the microprocessor 
to configure it), full or half duplex, and 
the HBAUD, or radio channel data 
rate. To find out the defaults, simply 
type MODEM at the cmd: prompt. 


The MONITOR commands are 
quite different than most other TNC’s. 
Again, consult the manual. 


7) Radio Connection Information 


The Data Engine manual includes 
information for wiring up the RS-232 
and power connectors. It includes no 
information for wiring up the radio. 


The Modem manuals (DE1200, 
DE9600, etc.) contain the information 
you will need for wiring up the PORT 
to RADIO cabling, at least on the Data 
Engine PORT side of the cable. 


Bits in the Basement 


by Bdale Garbee, N3EUA 


A lot of neat things have happened 
since my last column. My wife Karen 
NIFED and I spent a wonderful vaca- 
tion in France, including dinner with 
members of the TCP/IP community 
near Paris, The Rocky Mountain Pack- 
et Radio Association (RMPRA) dis- 
solution is complete, and a new or- 
ganization... the Colorado Packet As- 
sociation (COPA)... is being organized 
to fill the void. In the basement, 
KOYUM and I have just about solved 
the million or so little problems as- 
sociated with getting two 56k modems 
running with PC/DRSI card lash-ups, 
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WOYNE and I are building a 1200 
baud full duplex repeater to solve some 
local throughput problems, and I've 
spent amazingly little time writing 
software. IP in France For the last 
couple of years, “vacation” in the Gar- 
bee household has been a nebulous 
term. Most of my time off from work 
at HP has been spent tucking off to 
one or another ham gathering, for a 
jam-packed weekend, often including 
one or more presentations on high- 
speed packet, working a booth, or 
something like that. We've squeezed 
in a few short visits with family over 
holidays, but that’s about it. So, when 
my parents invited us to join them in 
Paris for 3 weeks this summer... well... 
it sounded too much like a real vaca- 
tion to pass up! 

Before we left for France, I con- 
tacted Remi Hutin, FE6CNB, who I 
had exchanged email with some time 
ago. Remi graciously offered to gather 
up some of his friends who are running 
TCP/IP on packet radio, and invite us 
all to dinner. Remi’s wife Nathalie 
cooked a superb dinner for the dozen 
or so of us, including my parents, and 
we all had a really wonderful time! If 
I got it all straight, there are three 
clusters of IP activity in France, one of 
which is centered around Paris, Remi 
is operating a station 24hrs/day with 
both a multi-lingual PBBS program, 
and the PEICHL NET program. This 
provides a gateway between the PBBS 
and SMTP mail systems, and causes 
his machine to serve as the focal point 
of their efforts, particularly since Remi 
has Internet access at work and there- 
fore an easy way to get software up- 
dates. Most of the other users in the 
area are running Macintosh systems, 
using the latest release of MacNet. 
There was some discussion before din- 
ner about Remi grabbing the sources 
for the Mac version from the U.S., so 
that they could fix a bug or two that 
they’ve found. It was at the same time 
frustrating and pleasing that the French 
IP community seems to be working 
through many of the same growing 
pains that we have here in Colorado. In 
particular, they’re discovering the 
frustrations of RF paths that “almost 
work,” are trying to get the different 
cells of IP activity connected over the 
existing NET/ROM network in 
France, and are just on the shy side of 
achieving a critical mass of folks to 
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make operating TCP/IP more than an 
oddity. 


Other than the evening with Remi 
and friends, we managed to stay pretty 
far away from our day to day routine! 
The only electronics I carted along was 
a brand-new Panasonic paperback-size 
shortwave radio, which brought us the 
BBC alternating with a local classical 
music FM station in Paris. We 
managed several days in museums, @ 
weekend in a 16th century chateau be- 
tween Le Mans and Tour, and a bunch 
of time sight-seeing around Paris. And 
the food was, of course, wonderful! 


The Flocd of '90 

Mother Nature must have a mean 
streak somewhere, I’ve been pretty 
good about cleaning the pine needles 
(we call them ‘leaves’...) out of the 
gutters on the house, but somehow one 
of the downspouts got solidly clogged. 
Along came a real downpour one night 
not long back, and we discovered the 
hard way that the low spot on the back 
gutter was directly over one of the win- 
dow wells for the Bit Basement. The 
result was nasty. Most of my floppies 
were lined up on the floor being or- 
ganized, and were destroyed by the 
mud that came in. The AT clone I do 
NOS and NOS-IN-A-BOX code on 
had water in it, but was still running 
because the water hadn’t quite gotten 
up to the bottom of the motherboard 
yet! Good thing too, because all of the 
backups were on the floor.... Lots of 
my schematics and data books on the 
table by the AT (right under the win- 
dow in question) were nasty goop by 
the time I got to them a day or so 


I took the event as a sign from my 
favorite deity that it was time to clean 
up the basement (!!!!). And I did, with 
lots of help from Karen. In fact, this is 
a sufficiently miraculous event that we 
bought a roll of film to document the 
evidence. I’ve had a few queries about 
just exactly what I’m hiding in the Bit 
Basement, so maybe I'll get the film 
developed in time to include a few 
pictures with my next column. If Bob 
is desperate for filler material, he may 
even print one or two in for your 
amusement! To make things doubly 
nasty, Don Lemley N4PCR of Grace 
Communications, suffered a flooded 
basement the same night! But in his 
case, it was a backed up sewer... you 
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can guess the rest. It's a good thing I'm 
not a superstitious kind of guy. 


S6KB Modems 

In the basement, Fred KOYUM and 
I have been working every Sunday for 
some time trying to get the bits and 
pieces of our 56kb WA4DSY modems 
together, with a pair of DRSI PCPA 
cards and KA9Q's “hs” driver in NOS. 
It has been, shall we say, educational? 

John Conner WDOFHG and I par- 
ticipated in the original beta-test of the 
DSY modems, and at that time we were 
very impressed with how easily the 
modems went together once we had all 
the parts in one place (though finding 
and getting all of them without going 
broke took most of a year — I sure am 
glad they’re shipping kits now, and not 
bare boards!).,.. but we were never able 
to make the kludged TNC-2's work at 
56kb on the radio side. So, after lots of 
effort, we got frustrated and never got 
the units on the air. Fred has been a 
wonderful catalyst. His enthusiasm has 
gotten me interested in hacking on the 
56kb hardware again, and making the 
silly things work. And his persistence 
has kept me working through some 
really frustrating problems. If you’re 
thinking about messing around with 
the DSY modems, or any high speed 
modem design, for that matter, I 
strongly suggest you find someone else 
to work with... it really makes a dif- 
ference! Some of our problems were 
just plain stupid, like interrupt con- 
flicts in the XT clone at one end keep- 
ing us from hearing anything, naive 
selection of a receive buffer size larger 
than the maximum configured inter- 
rupt buffer size, resulting in not hear- 
ing anything on the other end, destroy- 
ing an old 150W PC supply being used 
to power one modem when we hooked 
up the transverter with a rubber duck a 
couple of inches away and keyed 
down... who would have guessed it 
was that RF succeptible? Anyway, it’s 
been a struggle, but we're very close to 
going on the air for real. We’ve got 
packets flowing one way solidly, and 
will have the other direction going next 
Sunday, I’m sure. 


The world needs a good power 
supply design to take unregulated 
nominal 12V DC in, and provide an 
amp or two each of plus and minus 5V 
DC, regulated. I dug around a bit at 
work, and it looks like a circuit based 
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around the LT-1070 switching 
regulator IC from Linear Technologies 
would be really clean and not very 
expensive. Since the DSY modems 
need +/- 5V, maybe this would be a 
good kit for GRAPES or TAPR? 
Someone care to volunteer? Maybe by 
next time I'll be able to wax poetic 
about the joys of a S6kb link between 
my QTH in Black Forest, and Fred’s in 
Denver! Then I’ll have a real need for 
a couple of packet switches.... Cross 
your fingers for us.... 


10Ghz Stuff 

I mentioned long ago that John, 
WDOFHG, was working on putting 
schematics and PC Board artwork for 
the N6GN 10Ghz modem design (73 
mag 10/89, and Ham Radio mag 
12/89) into EE Designer ITI on his AT. 
He’s been at 95% complete for quite 
some time, missing the board 
geometry of a few stupid parts like 
PCB BNC connectors. John and I are 
working to get this finished up soon, 
and KE3Z at the ARRL Lab has agreed 
to help test out the PC Board design by 
funning a couple of boards and build- 
ing them up in the lab. 


If the design works, we’ve got 
enough parts to build up 6 links in the 
Bit Basement, and it’s highly likely 
that we’ll try to find some neat way to 
put them all to use! Maybe an all-digi- 
tal run for the ARRL 10Ghz contest 
next year? 10Ghz packet mobile... 


The astute observer may have 
noticed one of N6GN’s 10Ghz packet 
dishes in the photo collage advertising 
the 1991 Handbook in the latest issue 
of QST.... 


NOS 

Since the last issue of PSR, we've 
pretty much completely switched over 
from running the pre-NOS version of 
TCP/IP to running the new NOS ver- 
sion of NET in this area. There are 
some rough edges still, but there are a 
lot of neat new features, too. Since I've 
gotten a lot of questions about NOS 
lately, let me say a few things here. 

First, I hope I’ve made it very clear 
that I have no intention of working on 
documentation or integration of the 
NOS version of KA9Q’s software, as I 
did for the pre-NOS version. It was an 
almost full-time job for me, and my 


October 1990 - issue #40 


priorities have changed. Whether Phil 
will try to fill the gap himself by 
producing adequate documentation 
and installation aids is unclear. But 
don’t be too scared off, particularly if 
there’s someone in your area already 
running NOS. It’s not that hard to get 
going. 

The most intriguing recent addition 
to NOS, which isn’t exacily working 
right at the moment, is a preliminary 
implementation by Anders Klemets of 
the RSPF routing protocol. RSPF is an 
attempt to deal with some of the 
problems posed by the routing 
mechanisms in NET/ROM and the RIP 
support already included in NET, and 
it is tailored specifically for packet 
radio. I have high hopes that a fully 
functional RSPF implementation will 
give us the tool we need to build intel- 
ligent, dynamically routed IP net- 
works, We'll see as time progresses. 
Another neat development is that work 
is underway again on NNTP clients 
and servers. There is a brief paper in 
the CNC proceedings I received today 
about the use of NNTP for packet dis- 
cussions. I’ve talked before in this 
column about my belief that Usenet- 
style messaging may be the application 
that holds packet radio together and 
gets more folks interested and in- 
volved. The Terakoya news system by 
JKILOT and friends is an excellant 
Start, but it uses SMTP mail for for- 
warding articles from system to sys- 
tem. NNTP is a “real protocol” for 
transporting articles between 
databases, and between a database and 
a news user interface. Good NNTP 
Support for NOS will be a big step in 
the right direction. 

We're also very pleased that MSYS 
seems to be catching on with the local 
PBBS crowd. The latest version is very 
impressive, with few problems noted 
so far. I’ve had little to do with MSYS 
myself, except for FTP’ ing the bits to 
my machine at home, and mailing out 
floppies to some local sysops. All of 
the neat stuff isn’t fully functional yet, 
butI'm looking forward to the day very 
soon when we have solid PBBS 
to/from SMTP mail gateways work- 
ing, andcan forward PBBS traffic over 
our emerging IP backbone... 


Winfree 


I recently had the opportunity to 
replace the aging HP9000/550 running 
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as the unix machine ‘winfree’ in my 
basement with a not-quite-as-aging 
HP9000/330. Unlike the obsolete cus- 
tom-processor 550, the 330 is a 68020- 
based machine that can mun the most 
current revision of HP-UX, complete 
with integrated TCP/IP support. The 
transition went very smoothly, and 
I've now got a machine on the air full 
time that sports a mail gateway, and a 
USENET News installation. 


We're looking forward to getting 
NNTP working in NOS, and using 
winfree as the hub for news groups for 
COPA, etc. The new winfree has also 
made it possible for me to provide a 
real domain name server for use with 
NOS, and it’s been fun to play with on 
the air. can’t suggest strongly enough 
that you investigate finding a Unix 
machine with real TCP/IP support to 
act as one of the hubs in your local 
TCP/IP community. It really makes a 
difference! And with the price of full- 
blown Unix for 386 and 486 systems, 
it costs lithe more to put a fair Unix 
system on the air than it does to put up 
a heavily-loaded full-service PBBS. 
Think about it! 


More V.29 in Japan 

As I'm writing this, I’ve just 
received the first burst of dataon anew 
project in Japan, that puts what 
amounts to a TNC-2 clone with a V.29 
9600 baud “FAX modem” on a PC 
plug-in card (designed for the NEC 
PC-98, actually), I haven’t had time to 
look over the data package I received 
by email yet, but this is yet another sign 
of the popularity of V.29, particularly 
when used at 7200 baud, in Japan. I'll 
try to have more to say next time. I also 
have a pair of bare boards and Yamaha 
chips for the PRUG TNC-2 daughter 
card. Several other folks have reported 
that they are investigating the Yamaha 
V.29 modems, and it’s likely that we'll 
hear more before long. 


Kantronics Data Engine 

Phil Anderson at Kantronics reports 
that sales of the Data Engine have been 
brisk. I’ve talked about the base unit 
here before. When you order one from 
Kantronics, it comes with a daughter 
card for 1200 baud AFSK on one port. 
I recently got my hands on a pair of the 
new G3RUH/K9ONG-compatible 9600 
baud daughter cards for the Data En- 
gine, and hope to give them a workout 
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soon. I also received a couple of flyers 
that talk about different configura- 
tions, in particular you can get a unit 
with one 1200 baud modem, and one 
9600 baud modem. As far as I know, 
the Kantronics Data Engine with 9600 
baud modem, and one of the 
Kantronics DVR2-2 radios, is the only 
off-the-shelf 9600 baud packet solu- 
tion available in the U.S. today. Worth 
checking out... 


paper for the ARRL CNC this year. By the 
time you read this, the conference will have 
come and gone, and for the first time in 
several years, J won't have been there. The 
problem with amateur radio conferences is 
that the travel expense comes almostentirely 
Out of my own pocket...and my pocket is 
empty at the moment... 

The paper is a discussion of the ra- 
tionale for NOSINABOX, along with 
some details of the initial implementa- 
tion for the Grace PackeTen card, avail- 
able now. It also talks about some of the 
things Don and I would like to inves- 
tigate in the future. In concert with a 
paper by Don and Milt on the PackeTen 
card design, look for a copy of the con- 
ference proceedings to see what we're up 
to. 


Vacations, floods, 56kb modems, 
house painting, and so forth have all 
conspired to keep me from working on 
NOSINABOX for the Data Engine and 
PS-186. My level of motivation varies 
wildly, as does my available time. But 
progress is being made, and you'll 
probably be able to try out 
NOSINABOX on these platforms 
before the next PSR. In the meantime, 
the Grace PackeTen is available NOW 
for about the same price I expect the 
PS-186 to sell for, and it is a really neat, 
fast design. If you haven’t checked it out, 
you owe it to yourself to do so... 


Travel Next Year 

I've started thinking about where I'd like 
togonext year, I really enjoy attending ham 
gatherings around the country, and around 
the world, seeing what other folks are doing 
with packet radio. It’s fun to discover and 
discuss common problems, and a neat way 
to keep up with what is happening. 

If you know of a hamfest or con- 
ference or whatever next year in your 
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area that might be fun for me to attend 
with Karen, wherever you are, then 
drop me a line. The only real limiting 
factor will be the travel budget, so if 
there’s some chance of trading a 
presentation on one or another aspect 
of high-speed packet for a hotel room 
and/or expenses, so much the better! 


Newsletters 

T have also been really excited over 
the last few months to have interesting 
newsletters show up in my mailbox from 
various parts of the country. The stack 
next to my keyboard includes newslet- 
ters from NCPA, TPRS, and CAPRA, 
with others scattered around the house. 
A lot of really neat things are going on. 
Would it make sense for me to dedicate 
a portion of “Bits in the Basement” each 
issue to highlights from the various 
newsletters I get? Let me know what 
you think, And if you or someone you 
know puts out a packet-related newslet- 
ter, and the club treasury can afford a 
complimentary copy now and again, I'd 
love to see what's up in your area too. 


One of the goals I’ve had for this 
column is to try and help share infor- 
mation about neat things that are going 
on in our little niche of the hobby... 
when I was first getting started, N6GGN 
and I thrashed through a flurry of mail 
messages trying to figure out how I 
could avoid focussing on too narrow a 
set of people, and too narrow a set of 
activities. The newsletters help this a 
lot, as do your letters and electronic 
mail messages... 


Until Next Time 

As always, I really appreciate hear- 
ing from you. Let me know what you 
like and don’t like about Bits in the 
Basement, and I’ll know what to do to 
keep this column as useful and exciting 
to you as possible! 

I am reachable as 
bdale@col hp.com on the Inter- 
net, via any number of PBBS systems 
in this area (N3EUA @ WOLKD, 
WOLJF, KAOWIN, etc), on Com- 
puserve as 76430,3323, or by paper 
mail at: 

Bdale Garbee, NSEUA 
4390 Darr Circle 
Black Forest, CO 60908 

I'm miserable at answering paper 
mail, though, so try one of the 
electronic mail paths first, if you can... 


Until next time! 
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Interfacing the TAPR 
DCD State Machine to 
the Kantronics KAM HF 


by Lyle Johnson, WA7GXD 


Numerous packeteers have asked 
me if the TAPR DCD State Machine 
could be interfaced to the HF port on 
the Kantronics KAM. Not having a 
KAM, all I could say was, “Probably, 
but we haven’t tried it” 


At Dayton this year, one fellow 
promised to interface it and let me 
know how it worked. I gave him a 
DCD State kit free of charge to do this 
task. Neither he nor the kit have been 
heard from since! 


However, another ham, WA1JSG 
of Miami, Florida, indicated he would 
send me his KAM, realizing I would 
have to do some surgery on it to per- 
form the interface. As luck would have 
it, his unit arrived just before I left 
Tucson for an extended summer vaca- 
tion in Europe. 


Over the Labor Day holiday (a U.S. 
holiday that occurs the first weekend in 
September), I opened the KAM and 
began testing, measuring, etc. 


For the record, the unit I had is S/N 
61828 with firmware revision 2.85. 
The mods worked well on this unit; I 
don’t know what changes may have 
been made between this PC board and 
other revs, nor what effect other 
revisions of firmware may have on the 
performance of the unit. 

1 discovered that differential NRZI 
data was present on the microprocessor 
(U26; Hitachi HD63B03XP) at pins 17 
and 18, The NRZI data is also available 
at connector K8 pins 13 and 14. 

Careful monitoring with a digital 
storage oscilloscope revealed that 
positive-true DCD was generated from 
the KAM HF modem and applied to 
pin 24 of U26. I monitored off-the-air 
signals in packet, RTTY, AMTOR and 
CW modes, adjusting the RF gain on 
my TS-440S to weaken the signal so 
DCD was not reliably asserted by the 
KAM circuitry. This test revealed that 
modes other than packet did not appear 
to make use of the DCD signal at pin 
2A. 
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This is important because it implies 
that adding the DCD mod will have no 
negative effects on operation in other 
HF modes. 


The KAM provides no clock at a 16 
or 32 times multiple of the data rate on 
the HF port. There is a clock at about 
40 times the data rate, but this is not the 
correct ratio for our use. The internal 
clock option of the DCD State machine 
kit has to be used. 


Finally, since the KAM HF port is 
not capable of 1200 bps operation, the 
DCD clock can be optimized for 300 
bps operation by using a different 
clock output pin than the default 
(which is set for 1200 bps). 


Step by Step 

As you build the DCD State 
Machine kit, DO NOT install the 
jumper pins at the CLK jumper or at 
JMP. These pins are too tall to allow 
the completed assembly to easily fit 
inside the KAM case, No component 
on the PC board may rise taller than the 
body of a socketed IC. If your DCD kit 
uses an electrolytic capacitor for C2, 
consider replacing it with a tantalum. 
Recent kits use tantalum capacitors at 
C2 for reasons of physical size. 


At the CLK jumper, install a piece 
of insulated wire from the center pin to 
Ué4 pin 15 (on the bottom of the DCD 
PC board). This will select the internal 
clock at the proper multiple for best 
operation at 300 bps packet operation. 

Use a small piece of cut-off resistor 
lead to wire the JMP location pins 2 
and 3 together. This sets the State 
Machine for positive-true DCD input. 


The DCD PC board will fit snugly 
just above U26 and the timer chip, 
U23. I used a piece of Radio Shack 
double-sided foam tape for this pur- 
pose. Please consult the figure to 
clarify wiring. 

Connect the wiring hamess as fol- 
lows: 
¢ Brown (pin 1) to pin 14 of the IC 

(74HC4070) near the lower left- 

hand comer of U26 (+5 VDC). 
¢ Red (pin 2) to the empty hole 

nearest the edge of the KAM PC 
board labeled C53 just below U26 

(GND). 
¢ Violet (pin 7) to the other hole at 

C53 (DCD in). 
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e Gray (pin 8) to the DCD State 
Machine push-on jumper which is 
no longer used. Push this over K8 
pins 13 and 14 (NRZI in). 

¢ Yellow (Pin 4). Carefully pry U26 
from its socket, bend out pin 24 
and reinstall. Solder the yellow 
wire from the DCD State Machine 
to this free pin (DCD out). 

¢ Carefully align the PC board over 
U26 and U23. It should still allow 
you to swap the EPROM at U22, 
the TCM3105 modem IC at US 
and the serial EEPROM at U25. 

e Reassemble your KAM andenjoy 
more-accurate DCD.on HF pack- 
et! 


Notes from the TAPR 
Office 


by Heather Johnson, N7DZU 


Hello again! 


[had a great time with Lyle and our 
four oldest children this Summer visit- 
ing England and Switzerland! One of 
the highlights was attending the 
AMSAT UK Colloquium at the 
University of Surrey. It was stimulat- 
ing to be in a setting where SO many 
nationalities were represented! I was 
told that there were twenty-nine 
countries involved! 


I treasure the opportunity I had to 
meet these people and to witness each 
contributing valuable information for 
the good of all! I also found it great fun 
to meet men that Lyle has told me 
about for so long; men who have con- 
tributed so much, and made their mark 
in our outstanding hobby! If any of 
you get an opportunity to attend this 
convention in the future, I think that 
you will both enjoy and benefit by it. 


Thank you AMSAT UK. 


As you have all noticed, most of the 
address labels, membership cards, etc. 
coming out of the office are done 
manually. On the one hand, like 
Grandma making pie from scratch, you 
can tell that each of you is given human 
attention. On the other it may make 
you wonder why we, who claim to be 
high-tech, are archaic in this area. Iam 
becoming more computer literate, so 
expect to see some changes in the near 
sure “Onward and upward” as they 
say! 
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NOTE: 


Nuabers In Ceaerenthesea) 
eater ta virea nunber from 
she TAPR OCOD State Machina 
wiring herness. 


Thave a few short comments: 


1. If you have called our old 
telephone number (602-323-1710) and 
been frustrated by the operator not 
giving you our correct number please 
take note of our correct numbers: 


Voice (officially answered Tuesday 
through Friday, 10 a.m. - 3 p.m. MST) 
602-749-9479. ("Shhhh," don’t tell 
anyone, but I often answer the phone, 
when possible, at other than “official 
hours” as I would far rather communi- 
cate with you than with my answering 
machine!) 

FAX (always available) 602-749- 
5636. 


2. When ordering a DCD kit, please 
tell me WHICH TNC you plan to in- 
Stall it in, as I have extra information to 
send you that isn’t incorporated into 
the documentation yet. 

3. Start making plans to come to the 
1991 TAPR annual meeting. Once 
again there will be a hospitality suite to 
help welcome you. 
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4.1 am so grateful to those who help 
answer the technical questions that I 
receive. We have some more volun- 
teers! 


Carl Wall, VE3APY, 27 Stock- 
bridge Ave., Toronto, Ontario, 
Canada, M8Z 4M6. Carl says he will 
help anyone in the local area with 
memory upgrade mods to their TNC-2 
or clone. 

Joe Subich, AD8I, 7415 Hagerty 
Rd., Ashville, OH 43103 does a lot of 
TNC-2 and clone repairs and can 
answer BBS/HF operating questions. 

PSR #39 lists our other super volun- 
teers. 

5. A big and hearty welcome to all 
of the RMPRA folk. We solicit your 
input and consider your participation 
of high value. 

Until next time, 73s! 
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interfacing the TAPR 


PSK Modem to the 
Kantronics Data Engine 


by Lyle Johnson, WA7GXD 


Background 

The new Data Engine (DE) from 
Kantronics offers a number of unusual 
features. See the “First Impressions” 
article in this issue of PSR for more 
details. 

Data Engine modems are designed 
as plug-in modules to prevent obsoles- 
cence and maximize flexibility. Unfor- 
tunately, the internal form factor al- 
lowed for a plug-in modem makes it 
very difficult to design an internal PSK 
(satellite) modem. 


PSK Modem 

The TAPR PSK modem is designed 
to work in conjunction with an existing 
1200 bps modem. Specifically, the 
transmit PIT circuit with watchdog 
timer is “borrowed” from the host. This 
additional circuit would have to be 
added to use the TAPR modem with an 
unused modem “slot” in the DE. This 
wouldn't be too hard to design, but it 
would mean making another PC board. 
It would also mean dedicating a radio 
port and adding cost for those who 
simply want to add a PSK modem to 
their Data Engine. 


The standard Data Engine comes 
with a 1200 bps modem, the DE1200. 
This unit is based on the TCM3105 
modem chip, and includes additional 
circuitry to allow “open squelch” 
operation without DCD falsing. 


The internal modem, of course, oc- 
cupies the modem connectors, so a dif- 
ferent means of interfacing the PSK 
modem had to be devised. Kantronics 
consulted with TAPR prior to specify- 
ing the radio connector pinout. As a 
result, the Data Engine’s DA-15S (15- 
pin D-series) connector conforms to 
the proposed pinout of the 
TAPR/AMSAT DSP radio connector. 
It also has enough pins to serve as a 
combination radio and external 
modem disconnect. 


I attempted to work out a modifica- 
tion scheme to the DE1200 modem 
that would allow the Data Engine to 
work properly without having an exter- 
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nal PSK modem attached after the 
modifications were completed, and 
without modifying the radio cabling. I 
also wanted the external PSK modem 
to operate normally when attached to 
the Data Engine. To make it all more 
fun (ahem!), I tried to not violate the 
DA-15 connector pinout. 


Required Signals 

All special signals for the PSK 
modem interface have to be run to 
otherwise unused pins on the DA-15 
radio port connector. These signals 
are: 


1) 32x Transmit clock, TTL levels. 
This signal is available within the Data 
Engine and may be tapped with a small 
jumper added to the DE1200 PC board. 


2) Transmit Data signal, TTL 


’ Jevels. This signal is also available and 


can be tapped with a jumper on the 
DE1200 board. 


3) DCD in and out at TTL levels. 
The PSK modem must be able to inter- 
cept the DCD signal from the DE1200 
and insert its own DCD signal when in 
PSK mode. Fortunately, the DE1200 
allows an external DCD input, and the 
Data Engine can be commanded in 
software to use this external DCD in- 
stead of the DE1200’s normal DCD. 
We only have to use this input rather 
than intercept the normal DCD. 


We will make use of the RFDCD 
input at pin 8 of the DA-15 connector. 
There is an auxiliary DCD we could 
use instead, but it requires a positive 
polarity DCD rather than the negative 
polarity provided by the TAPR PSK 
modem. To get at an unused TTL in- 
verter on the DE1200 modem board is 
more trouble than it is worth, so I 
decided to sacrifice the RFDCD func- 
tion. 


4) RXD in and out at TTL levels. 
This is also so the PSK modem can 
drive the HDLC chip inside the TNC 
tather than have the normal 1200 bps 
modem provide this signal. 


Data Engine Considerations 

In the Data Engine, the HDLC con- 
troller is a CMOS chip. When the 
DE1200 is installed, the fastest data 
that will be applied to the HDLC chip 
is 1200 bps. This means we can insert 
a series resistance of about 10K ohms 
between the TCM3105 modem chip 
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and the Z85C30 HDLC chip with no 
undesirable effects. 


The 10K resistance will be trivial 
for the PSK modem's output to over- 
ride, yet allow normal operation of the 
modified DE1200 in a Data Engine 
with standard cabling or with no PSK 
modem attached. 


The modified DE1200 now meets 
all of our design criteria. We have only 
to assign pin numbers to the DA-15 
connector, then get on with the 
modifications! 

The DSP radio connector specifies 
several input and output pins with sug- 
gested functions. The ones we will use 
are: pin 14-RTS (TTL output) for X32 
clock; pin 12 - SPARE 1 (TTL output) 
for TXD from the Data Engine; pin 4 - 
+DOWN (TTL output) for RXD input 
to the Data Engine. 


The last pin violates the suggested 
direction for the pin. The other input, 
Pin 15 - CTS, is used by the DE1200. 
Pin 13 - SPARE 2, pin may be wired to 
supply power to an extemal device and 
I refrained from using it to prevent 
possible damage to a PSK modem that 
could be connected to a Data Engine 
which has +12 volts DC on this pin. 
This pin could be wired up to optional- 
ly provide power to the PSK modem 
when the Data Engine is turned on. 


Mods to the DE1200 Modem 
Board 
* 32X CLOCK - adda jumper from 
INT! pin 5 to EXT] pin 15. 
¢ TXD OUTPUT - add a jumper 
from INT1 pin 3 to EXT} pin 13. 
¢ RXD INPUT - add ajumper from 
INT1 pin 4 to EXT1 pin 6. 

Cut the trace that routes from the 
TCM3105 modem chip to INT] pin 4. 
I cut it on the top of the board between 
the words “COPYRIGHT” and “1990” 
on the silkscreen legend. It is the small 
trace just below the printing (not the 
trace beneath the printing). See the il- 
lustration for details. 


Scrape the solder mask from the 
trace on either side of the cut and care- 
fully solder a 10k resistor to bridge the 
cut. I scraped the area just to the left of 
and below the “C” in “COPYRIGHT” 
and below and to the right of the “.” in 
“CO.”. The resistor fits easily in the 
space remaining. Just be sure the lead 
of the resistor doesn’t touch the screw 
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at spacer SP2 when you re-install the 
modem board! 


If you haven't already done so, add 
a jumper at the “V23" position to make 
the DE 1200 use the 1300/2100 Hz tone 
pair rather than the 1200/22000 Hz 
tone pair when sending. This will help 
DCD operation at stations receiving 
your transmissions, 

Inspect your work, then re-install 
the DE1200 modem and get the Data 
Engine on the air. Verify that the 
DE1200 works as before. 


Cable Wiring Between the Data 
Engine and the PSK Modem 

Prepare the following cable. I sug- 
gest using shielded cables for all con- 
nections, and grounding the shield to 
the cases of the connectors. 


In my shack, I have standardized on 
5-pin DIN connectors for all my data 
equipment. Thus, I use a female 5-pin 
DIN on adapter cables such as this one. 
This way I can switch between various 
TNCs at will. If you want to use a male 
5-pin connector, the pinout remains the 
same. 
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CUT TRACE AT "O" 


SOLDER 18K RESISTOR ACROSS "x" 
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DE12g9@ PC BOARD 


The cables should be long enough 
to allow you to place the equipment 
according to your preferences, and 
with enough slack so you can operate 
the equipment with the covers off to 
troubleshoot. It shouldn’t be longer, 
though, or you will simply be increas- 
ing your chances of RFI. 

NOTE: Don’t make the cables a 
multiple of 19" if you expect to have 
much 2-meter RF in your shack, unless 
you enjoy pain... 
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Cable Wiring Between Data Engine and 
PSK Modem 


DA-15P DIN-5 DIN-8 
12 8 
4 5 
8 4 
2,7 


INTi ExXT1 


ROO JUMPERS: 
INTi €XT1 

3 13 

4 +=] 

s 15 


aan ae nnnenwanwaan aan we ewe een nnn wow ow sueswnd 


PSK Modem Considerations 

Be sure to set the clock jumper for 
32X clock in the Manchester (satellite) 
mode, This is JP6 pins 5&6 in the 
PSK-1 (see page 29 of the March 1990 
PSK 1 manual) and PAD-2 for the 
TAPR PSK modem (see page 23 of the 
March 1990 TAPR PSK Modem 
manual). 


If youare using the PacComm PSK- 
1, it must have power ON whenever 
you use the Data Engine and have the 
two units cabled together — even if 
you are planning on using the intemal 


FUNCTION 

Ox CLOCK 

TXD 

AXD 

OCD 

GND {DIGITAL 
PTT (OPEN DRAIN) 
XA (AUDIO 


DO NOT CONNECT 
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DE1200 FSK modem. The TAPR PSK 
modem may have power removed 
under this circumstance. If you plan on 
using the PacComm PSK-1, see the 
“First Impressions” article in this PSR 
for some important notes. 


Data Engine Software 
Commands to Enable the PSK 
Modem 

Enter the command 
MODEK 2, F0LL, 1200 

for satellite operation, or 
MODEM 2, RAL, 1200 

for terrestrial applications which 
are not full duplex. 


Be sure to enter 
MODEM 0, HALF, 1200 

for normal (A)FSK operation. The 
“0” selects the “open squelch" DCD 
output from the DE 1200, while the “2” 
tells the Data Engine to accept DCD 
from the RFDCD input which is driven 
by the PSK modem. 


Conclusion 

I have made these modifications to 
Data Engine s/n 850 01470 and 
DE1200 modem s/n DEM 1198. I used 
an early TAPR PSK modem and a Pac- 
Comm PSK-1 s/n P10252, All units 
worked as described above. These 
mods will allow you to use the Data 
Engine in your satellite shack without 
sacrificing a radio port to the PSK 
modem. 


Have fun! 
DSProgress 


by Lyle Johnson, WA7GXD 


In the last PSR, I described a little 
of the effort involved in getting a PC 
board layout done for a board as com- 
plex as the DSP 1. Never mind the 
complexity of the circuitry itself, 
which also takes a while to dream up 
and turn into a schematic diagram! 

The first five prototype boards were 
delivered in late June. The first one 
was populated and testing was begun 
just before I left for a month’s vacation 
in early July. At the time I left for 
vacation, almost nothing worked... 

Since early August (I am writing 
this in late September), a lot of 
progress has been made. Design exrors 
have been found and repaired. Several 
equations describing the program- 
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mable logic had errors and have been 
corrected. It is nice to use program- 
mable logic, though, since most errors 
can be fixed simply by re-program- 
ming the parts! Without boring you 
with the details, there are only two 
known “gotchas” remaining on the 
board. 


The 8530 interface is working just 
fine. 


The DSP memory can be loaded by 
the host PC and the DSP can then run 
the program loaded. 


All DSP 1/0 ports, including the 
handshaking 16-bit port to the PC and 
the analog I/O are working as ex- 
pected. 

The A/D and D/A can be clocked by 
a phase-adjustable free-running clock 
under DSP control, or they can be 
directly strobed by the DSP under 
software control. 


The PC status and control registers 
work. 


A debugger/monitor is being writ- 
ten by Dan Morrison, KV7B, and all 
attempted functions are working 
properly, with more to come. 


The two big bugs are: 


1) The 16-bit wide PC access sys- 
tem isn’t working. The PC accesses 
the board as an 8-bit peripheral. It is 
being tested in an old, non-IBM AT 

“clone” and I understand there is a lot 
of variation in clones as to their reac- 
tion to [/O wait state requests. This 
problem is being worked on, but until 
the board is tested in more platforms 
we won "t know if it is a generic prob- 
lem or a problem specific to certain 
motherboard manufacturers and/or 
chip sets. 

2) The bigger bug is one that causes 
the DSP to crash when the PC accesses 
DSP memory while the DSP is run- 
ning. There is a simple workaround, 
but it steals more cycles from the DSP 
for each access. This one is getting all 
our attention now and I will be 
surprised if it is still a problem by the 
time this PSR reaches you. 

There are two prototypes running as 
this is being written, and two more 
should be up within a week's time. At 
least one software developer has a 
prototype board on a full-time basis. 
We expect to place two more boards in 
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other software writer’s hands as soon 
as the boards come to life. 


Once we have the two bugs 
squashed, we will do another board 
layout, then build a couple more 
boards. As soon as the hardware is 
thus proven, and a minimum number 
of applications exist to make the board 
useful, we will get into the documenta- 
tion cleanup and kit production phase 
of the project. 

It remains to be seen if this board 
can be kitted or if it must be assembled 
and tested. A six-layer board is not 
trivial to build. On the other hand, with 
care and the proper tools it is nothing 
to be afraid of. 

Watch this space. This project is 
hot! 


Software Library Update 


by Bob Nielsen, W6SWE 


Since the July, 1990 issue, the fol- 
lowing changes and additions have 
been made to the TAPR software 
library: 


Revised: 

Disk1 APLINK - version 4.19 

Disk6 § PKTTERM (shareware demo 
of Packet-Plus and Packet- 
Gold) version of 8/22/90 

Disk 10 ROSE switch - version of 
7N380 

Disk 16 W®RLI BBS - version 11.13 

Disk 19 — LAN-LINK - version 1.58 

Disk 21 MSYS - version 1.09 

Disk 22  G8BPQ switch - version 3.59, 
plus several utilities (MH, 
BPQTERM, HELP and MONI- 
TOR) by Paul Hounslow, 
G4YFE have been added to 
disk 

New: 

Disk 28 TEXNET Applications - ver. 
1.5 - software for use with the 
TEXNET packet switch by 
Texas Packet Radio Society. 

In addition, TAPR is now offering all 


of the library selections in 3-1/2 inch, 
720K MS-DOS format. The two-disk 
sets in 5-1/4 inch 360K format will 
fit on .a single disk in 3-1/2 inch 
format. 
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TUCSON AMATEUR PACKET RADIO 
P.O. BOX 12925 TUCSON, AZ 85732 
602-749-9479 (VOICE) 602-749-5636 (FAX) 


ORDER FORM -- Kits -- Firmware -- Software -- Membership 
(All prices are payable in U.S. funds and include shipping and handling except foreign air) 
Please allow six to eight weeks for your order to be shipped 


KITS and FIRMWARE 
PSK Modem BT 0 | 0 a 
Cabinet for PSK Modem 8.00 (5.00 when ordered at same time as modem) ......... 00sec eeees 
KONG 9600 Baud Modem P39 0 | 0 a 
TNC 2 Tuning Indicator P33 6 | 0 
XR2211 DCD Mod. 11.00 ..... thee e nee e ecw e cree eeeeee see ee tee eee ete teens 
State Machine DCD Mod. LO AS | 
State Mach. DCD w/Intemal Clock 21.00 For Packet Communicator, KPC2 or ANY other TNC ............+-4- 


PK232 Modem Disconnect Upgrade 17.50 2.0... cc ccc cee cc cee ee ee ee eee ee eee ea eee eee een eeeeees 
TNC 1 Upgrade to TNC 2 J: 0 a 
* TNC 1 Upgrade Memory kit 7-400 6 © paar 


* When purchased w/TNC | upgrade. Includes 32k RAM and 1.1.7 w/KISS EPROM 


32K RAM w/TNC2 update docs 19 | ¢ rn 
TNC 2 ver 1.1.7 w/kiss (27C256) 12.00 (includes new 1.1.7 Commands booklet) ........ 20. c eee eee eens 
TNC 2 WASDED (27C256) 12.00 ...... Seen eee cee eet eee eee te eee eer eee esse eee e eee eee 
TNC | WASDED (2x2764) +20 | * 
TNC ! KISS (2764) 12.00 . occ cc cee s cc ccc nce cee eee ee ete tbat een e eet ee tenes eeees 
TNC 2 KISS (27C256) 12) 8 
1.1.7 Commands beoklet 3.00 (The full TNC2 command set for 1.1.7) ......0 2c cece et eectceree 
PSR sets, [ssue #1 to present 0 | © 


SOFTWARE .. Please circle disk numbers requested. 


Qty. 


Total 


1. APLINK - WSSMM - Runs MBO & BBS 16. WORLI BBS - W@RL] - BB system 

2. BB - AA4RE - A multiconnect Mailbox 17, YAPP - WA7MBL - Terminal program 

3. C-BBS - K3RLI/AG3F - BBS w/sources 18/18a INTRO TO TCP/IP - Much info on TCP/IP* 

4. EZPACL! - M. [mel - NTS formatter 19, LAN-LINK - G32CZ - Terminal program 

5. MONAX-NK6K/WBG6YMH - Gathering system stats 20. ARES/Data - WNGLNGKL - Emergency data system 

6. Packet S/W - WEGUUT - for PK 87,88,232 21. MSYS - WA8BXN - BBS/TCPIP/node System using KISS 

7. PBBS Lists - WOZRX - Master PBBS lists 22, NODE - G8BPQ - Packet switch/BBS networking pkg. 

8. R9S - WDSIVD - Binary conversion utility 23. COMPRESSION/ARCHIVING Utilities, .ZIP, .ARC, .ZOO & .ICE 
9/9a ROSESERV - KA2BQE - BB and server for ROSE* 24. THS - HBOSCVV - Term. program for TNCs w/WAS8DED 
10. ROSE Switch - W2VY - The ROSE executibles firmware 

11/lla TCP/IP Plug & Play - KA9Q* 25. NTS Traffic Generator - VE4UB 

12/12a TCP/IP Sources - KA9Q* 26, NM1D DOSgate - NM1D - Remotely operate PC via packet 
13. TNC-! Source code - TAPR - TNC-1 Sources 27. SV7AIZ BBS - SV7AIZ - Multiuser, multiport BB system 

14, TNC-2 Software notes - N2WX - 1.1.0 thru 1.1.7 28. TEXNET Applications - Software for use with TEXNET packet 


15. WA7MBL BBS - WA7MBL - BB system 


* Indicates two-disk package (one disk in 3-1/2 in. format), We attempt to provide the latest versions of all software. 
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Total disks circled - 5-1/4 in. MS-DOS format (9, 11, 12 & 18 are 2 disks ea) — __ x $2.00 » 
Total disks circled - 3-1/2 in. MS-DOS format x $3.00 = 
Credit Card Number ____ Expires 
(VISA/Mastereard only) Subtotal 
Signature 
Arizona Residents 
For AIRMAIL orders to be shipped outside North America, please contact TAPR. add 5% tax 
TAPR is a non-profit, volunteer operated amateur radio organization. Membership in TAPR, 
including a subscription to Packet Status Register, the TAPR newsletter, is $15 per year in the 
US and possessions, $18 in Canada and Mexico, and $25 elsewhere. Membership and PSR Membership 


subscription cannot be separated. $12 of the dues is allocated to Packet Status Register. 


If applying for membership, New or Renewal 
Airmail outside N.AJ WO 
Call 
Name Sign 
VISA/Mastercard add 4% _ 
Address 
City & zIP 
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09/90 


? 
The Tucson Amateur Packet Radio Corporation isa non-profit, scientific research and development corporation. TAPR is chartered | 
in the State of Arizona for the purpose of designing and developing new systems for packet radio communication in the Amatcur $ 
Radio Service, and for freely disseminating information required during, and obtained from such research. 


The officers of the Tucson Amateur Packet Radio Corp. are: 


Lyle Johnson, WA7GXD President 

Harold Price, NK6K Executive Vice President 
Greg Jones, WDSIVD Secretary/Treasurer 

Bob Nielsen, W6SWE VP for Member Services 


The Packet Status Register is the official publication of the Tucson Amateur Packet Radio Corporation. Explicit permission is 
granted to reproduce any material appearing herein, provided credit is given to both the author and TAPR. 
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PO Box 12925 
Tucson, AZ 85732-2925 
Phone: 602-749-9479 
FAX: 602-749-5636 
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Tucson, AZ 85718-3915 
CompuServe: 71540,2364 
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